Re: another "xmlfs" proposal

[olafBuddenhagen]

Hi,

On Sat, May 03, 2008 at 11:53:18AM -0700,
gnubie10-bugsoccer@yahoo.com.br wrote:

> DOM is a(n object) model for xml documents. In principle, using it or
> not is not the point. I think antrik wanted to say to translate the
> data model of the xml document to an directory structure so that the
> file _path_ resembles the [document structure][0] (PS: example, not
> puting extra nodes to amend the notation).

I'm not sure that is what I want to say, as I'm not sure what you are
trying to say here... :-)

The idea is that it would be desirable that working on the XML
filesystem would feel similar to working on a DOM tree -- unless it
proves too awkward...

> When you use XSLT, you have to select nodes using XPath and learning
> it was vary easy to me

Not as easy as you think, it seems... See below.

> because they followed the [principle of the least surpise][3] doing
> things as much compatible with unix directory naming convention as
> possible

Not sure whether this was an explicit goal. It's true though that XPath
allows accessing the DOM structure in a fashion that quite resembles
file paths, and thus probably forms a good base for xmlfs.

> Take this file named 'tom_sic.xml'
[...]
> I made some corrections on [Charly Caulet's example][4]

Would be useful if you could sum up the changes.

> (This (PS: unnecessary) comentary is just the unique prompt i think i
> will have to say to avoid saying "something et al." (meaning
> "something and all"). "Al." is abbreviation to "alumni".

Wrong. The use of "et al" in English comes from latin. It's an
abbriviation of "et alii"/"et aliae"/"et alia", and translates to "and
others".

Aside from that, I have no clue what you are trying to say in this
sentence...

> (I know my english is bad. But if I do no correct, anybody won't
> correct me and I wont learn.

Well, if you know your English is poor, that's just more reason to keep
the style as simple as possible, to make it understandable at all... :-)
As it stands, your mail is *extremely* hard to follow.

> See the following typescript:
> 
>     > xpath tom_sic.xml "/libraries/pouet:library/book[isbn = '4242']"
>     Found 1 nodes:
>     -- NODE --
>     <book>
>                 <author>Mark Twain</author>
>                 <title>La case de l'oncle Tom</title>
>                 <isbn>4242</isbn>
>             </book>
>     > xpath tom_sic.xml "/libraries/pouet:library/*[contains(name(),'ook')]"
>     Found 2 nodes:
>     -- NODE --
>     <book>
>                 <author>Mark Twain</author>
>                 <title>La case de l'oncle Tom</title>
>                 <isbn>4242</isbn>
>             </book>-- NODE --
>     <book />
>     > 

What is this supposed to tell us?...

> A sample result is 'foo.xml':
> 
>     <?xml version="1.0" encoding="utf-8"?>
>     <dirtree >
>       <directory name="xml">
>         <file name=".dir.pl.swp"></file>
>         <file name="dir.pl"></file>
>         <file name="final.xml"></file>
>         <file name="foo.pl"></file>
>         <file name="foo.xml"></file>
>       </directory>
>     </dirtree>
> 
> I made by hand, as a proof of concept, this directory tree:
> 
>     > find dirtree/
>     dirtree/
>     dirtree/directory
>     dirtree/directory/directory
>     dirtree/directory/directory/@name
>     dirtree/directory/directory/file[@name = 'foo.xml']
>     dirtree/directory/directory/file[@name = 'foo.xml']/@name
>     dirtree/directory/directory/file[@name = 'dir.pl']
>     dirtree/directory/directory/file[@name = 'dir.pl']/@name
>     dirtree/directory/directory/file[@name = 'foo.pl']
>     dirtree/directory/directory/file[@name = 'foo.pl']/@name
>     dirtree/directory/directory/file[@name = '.dir.pl.swp']
>     dirtree/directory/directory/file[@name = '.dir.pl.swp']/@name
>     dirtree/directory/directory/file[@name = 'perl5.8.8.core']
>     dirtree/directory/directory/file[@name = 'perl5.8.8.core']/@name
>     dirtree/directory/@name
>     > find dirtree -type f -print0 | xargs -0 grep -v "notafilename"
>     dirtree/directory/directory/@name:xml
>     dirtree/directory/directory/file[@name = 'foo.xml']/@name:foo.xml
>     dirtree/directory/directory/file[@name = 'dir.pl']/@name:dir.pl
>     dirtree/directory/directory/file[@name = 'foo.pl']/@name:foo.pl
>     dirtree/directory/directory/file[@name = '.dir.pl.swp']/@name:.dir.pl..swp
>     dirtree/directory/directory/file[@name = 
> 'perl5.8.8.core']/@name:perl5.8.8.core
>     dirtree/directory/@name:hurd

It would help if your example directory tree actually matched your
example XML file... there is no "hurd" directory there.

> That day, i realized some facts. had to try other possibilities but
> take this one just as a main part of the desired result. The
> interesting one is that, like the special file with name "*" from
> httpfs (that i could not use yet) which separates the local namespace
> and the foreing ("away", don't know, please correct) one,

"foreign" is OK. I have no clue what you are talking about, though...
Perhaps because I never tried using httpfs :-)

> using "[" and "]" to enclose the conditional expression that selects
> nodes in a xpath, the XPath creators used the pattern of an array
> element qualified identifier from C language.

Where is the parallel?...

> May be if we do "ls dirtree/directory/directory/" we should get "@name
> file[]". This solves the problem of having more than one node.

I don't understand that.

> "Special file" as the unix concept. Plan9 takes the "everthing is a
> file" paradigma.

What are you aiming at?...

> It is not trivial to select an commentary with xpath (not to me).

All I can say is: Learn your XPath :-)

I didn't know shit about XPath up till now, and it took me maybe half an
hour to learn enough to see why your attempts were wrong and how to do
it correctly; and some two or perhaps three hours to see how things fit
together in general (both in XPath 1.0 *and* 2.0), so I can explain the
situation using proper terms.

>     > xpath tom_sic.xml "/libraries/pouet:library/*[node()]"

This should select all element nodes below /libraries/pouet:library/
having any children... Which is just what it does in your example :-)

If the idea was to select *all* nodes below /libraries/pouet:library/,
it is doubly wrong: "*" selects all nodes of the *principal node type*,
which in this case (in a path expression step) means: all element nodes.
It's a shorthand for child::element().

And node() is not some special predicate expression, but a node test.
(In XPath 2 it's in fact a "kind" test, which can be used in a node
test, but also in sequence type expressions...) The way you used it, it
is a shorthand for child::node().

>     > xpath tom_sic.xml "/libraries/pouet:library/*[comment()]"

Same situation: This expands to "child::element()[child::comment()]",
i.e. all elements that have any comment children. As expected, there are
none.

If you wanted to select any comments below /libraries/pouet:library/,
the correct expression is "/libraries/pouet:library/comment()" .

(I think in XPath 2.0 you could also do something along the lines of
"/libraries/pouet:library/node()[. instance of comment()]" ...)

> Diging further at [w3c recommendations][1] i found that comment() is
> for backward compatibility.

Eh? Where did you read such a statement?

>     > xpath tom_sic.xml "/libraries/pouet:library/*[not(comment())]"

That returns all element nodes that don't have any comments as children
-- which are all element nodes in this case.

> To conclude. May be an comment is not an proper node.

Sure it is.

> When i did that directory tree, i had to decide that the "name"
> attribute of "directory" element "disambiguousate" (sorry the
> neologism usualy makes sence in portuguese, please correct me)

Disambiguate. How about using a dictionary? :-)

And again, I do not understand the statement...

> (We wont be using ad-hoc xml files. It must be valid following certain
> constraints.

Why?

> I used to think the XML document type declaration (thought the 'd'
> from DTD was "document") as an separated thing. Now i see it is an
> optional part of the same thing. If "curious#balise" can't be an name
> for an xml element, it can not be an name for a file on an xmlfs ("xml
> file system" as a concept, not as an implementation).

Well, it can be useful to have an option to accept only valid XML; but
certainly not mandatory.

> [...] wont setup an file system translator server.  The `<!ELEMENT
> dirtree (directory)>` is missing and there is a file without name.

If the document was already invalid, why bother? There are perfectly
good reasons to edit an invalid document -- not least, to make it
valid...

> Now, with a(n?) [well formed xml][2] "../dir.xml",

You mean valid I believe... A not well formed document wouldn't even be
parsed by any compliant XML parser, so no need to discuss it at all.

> I must say (again) that I don't want to put any kind of file inside an
> xml. Althought it looks like possible.

Well, I for my part have no doubts that it's both possible and useful to
serialize arbitrary directory structures. Only thing I'm sceptical about
is whether it can be done in a fully complementary fashion to the XML
translator, so that stacking one on top of the other would result in the
original directory tree/document...

But maybe that's not even what you were talking about. It's not really
clear from your description :-(

> (PS: actually the files aren't been serialized/unserialized)

You mean not storing the file contents? That would make the whole thing
rather pointless.

-antrik-