Re: another "xmlfs" proposal

2008-05-04 Thread olafBuddenhagen
Hi,

On Sat, May 03, 2008 at 11:53:18AM -0700,
[EMAIL PROTECTED] 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 --
> 
> Mark Twain
> La case de l'oncle Tom
> 4242
> 
> > xpath tom_sic.xml "/libraries/pouet:library/*[contains(name(),'ook')]"
> Found 2 nodes:
> -- NODE --
> 
> Mark Twain
> La case de l'oncle Tom
> 4242
> -- NODE --
> 
> > 

What is this supposed to tell us?...

> A sample result is 'foo.xml':
> 
> 
> 
>   
> 
> 
> 
> 
> 
>   
> 
> 
> 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/[EMAIL PROTECTED] = 'foo.xml']
> dirtree/directory/directory/[EMAIL PROTECTED] = 'foo.xml']/@name
> dirtree/directory/directory/[EMAIL PROTECTED] = 'dir.pl']
> dirtree/directory/directory/[EMAIL PROTECTED] = 'dir.pl']/@name
> dirtree/directory/directory/[EMAIL PROTECTED] = 'foo.pl']
> dirtree/directory/directory/[EMAIL PROTECTED] = 'foo.pl']/@name
> dirtree/directory/directory/[EMAIL PROTECTED] = '.dir.pl.swp']
> dirtree/directory/directory/[EMAIL PROTECTED] = '.dir.pl.swp']/@name
> dirtree/directory/directory/[EMAIL PROTECTED] = 'perl5.8.8.core']
> dirtree/directory/directory/[EMAIL PROTECTED] = '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/[EMAIL PROTECTED] = 'foo.xml']/@name:foo.xml
> dirtree/directory/directory/[EMAIL PROTECTED] = 'dir.pl']/@name:dir.pl
> dirtree/directory/directory/[EMAIL PROTECTED] = 'foo.pl']/@name:foo.pl
> dirtree/directory/directory/[EMAIL PROTECTED] = 
> '.dir.pl.swp']/@name:.dir.pl..swp
> dirtree/directory/directory/[EMAIL PROTECTED] = 
> '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?.

Re: Bug-hurd Digest, Vol 66, Issue 4

2008-05-04 Thread Arne Babenhauserheide
El Saturday, 3 de May de 2008 19:30:03 Sergiu Ivanov escribió:
> > Arne Babenhauserheide wrote:
> > > > > support for browsing tar files.

> > Python does have tar support:
> >
> > http://docs.python.org/lib/module-tarfile.html
> >
> > Thought it might interest you anyhow :)
>
> Thanks a lot! I didn't know Python can to _that_ much :-)

It was the same for me, but I just thought: 

"Hey, maybe there's already a module for tarfiles. Let's ask Google."
:) 

And what happens most times also happened there: 

"Yes, Python can already do that out of the box" :) 

A nice visualization: 
- http://xkcd.com/353/ 
;) 

Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Ein Würfel System: http://1w6.org - einfach sauberere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.