You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/07/15 20:39:15 UTC
[RT] The perfect repository might be just under your eyes
Everybody who tried knows that using a relational database to store
semi-structured content is a suicidal move. You can use all the
object-relational or xml-relational or text-indexing database-specific
capabilities of the world and still feel like there is something wrong.
It's like storing relational data on the file system directly. Sure, it
can be done, but it feels wrong, no matter what.
With linotype, I thought about what repository to use, went over the
whole stinking range and decided, WTF, I'm going to write on the
stinking file system and forget it.
It was lazy-driven design. Less is more to the very bone. But it might
be the most revolutionary move in content management over the last few
years. Let me explain why.
I gained tons of flexibility, an access API named java.io which is very
practical and simple to use. moving stuff around? mv. copying? cp.
copying remotely thru a secure channel? scp. backup? cronned tar.
replication on multiple machines? untar.
Considering doing the same thing over, say, a WebDAV repository. You
need to write the clients that do that... or... you have a
(macosx-like) webdav file system mounter.
now.
If you think about it, there are not many file systems around. FAT?
crap. NTFS? better but still crap (doesn't even have symlinks, go
figure) and then we have the entire range of POSIX filesystems that
differ for implementation but they all share the same design.
This morning I found this
http://www.namesys.com/v4/pseudo.html
and I was *litterarely* blown away.
The concept seems borrowed right from our sitemap:
- foo -> a file
- foo/ -> a directory
the stupid web servers default behavior of interpreting foo as one or
the other depending on the file system layout prevented people to
understand the "semantic" difference of the two on the web, but it also
prevented the web people to influence the file system design.
I admit that I thought that POSIX was so carved in stone that I never
even considered extending it to provide the functionality that was
missing right at OS level! So I'm guilty as anybody else.
But think about it:
/document
is the full document
/document/html/body/p
is the content of the p node, so
echo "whatever" > /document/html/body/p
changes the content of the node! right from the command line. You can
use symlinks to share content between your document!!! you can have ACL
at the node level!!! just write an xgrep and you are able to do xpath
searches from the command line! just add an XML parser and you are able
to do something like
cat xhtml.dtd > /document/@schema
and when you save your stuff as /document, the file system will trigger
an error if the file is not valid!
Imagine all the stuff that you can do with this! and the file system
can be journalled, offer node-level transactional capabilities, you
name it! at right into the OS. fast fast fast!
What? it's not remote, you say? get over it: scp and duct tape can make
it as remote as anything.
Forget WebDAV, forget JSR170, your perfect repository might be, thanks
to the pseudo-file concept, just a new linux module away.
--
Stefano.
Re: Mime-Types
Posted by Tim Myers <ph...@pirouline.sts.jhu.edu>.
I screwed up my argument by over complicating the example:
> > finder? They use file extentions!!!
>
> I think this is not the case.
Me too, but i was wrong. It so uses file extensions. It's so sad. See below.
>
> > OS9- had file attributes to store typing
> > information.
>
> I believe this is true for OSX as well.
Again, I thought this was true until I proved to myself otherwise.
>
> > That has it's advantages and disadvantages- Unix has this
> > perfectly wonderful system for typing, /usr/bin/file and /etc/magic.
>
> hmmm, a matadata inference system is a good help against lazyness, but
> it's never as effective as explicit metadata. IMHO, POSIX falls short
> in that domain and UNIX just tried to work around it with automagic
> type discovery (which <?xml version="1.0"?> shows it can be a massive
> mistake!)
Fair enough, but my point is that apple moved away from explicit metadata.
> > Here's a fun exersize.
> If your download is on HTTP, the wrong mime type is probably given by
> your web server. In this case, this is not OSX fault at all! It's your
> web servers!
OK, much simpler exercise (OS X only):
Find an mp3 file on your hard drive.
Get info for that file.
Take note of:
filename:
type:
Rename that file, using finder
Get info for that file.
Take note of:
filename:
type:
I found the results to be very disturbing. If you try it, I trust you will to.
If you renamed it .zip and double clicked, you'll see just how disturbing it
can be.
> If you have an XHTML page with some inlined SVG, what MIME type is
> that? XML (goes to my xml editor), XHTML (goes to my browser) or SVG
> (goes to my vector graphics editor)?
Without much explanation i will claim that it's file type is xhtml.
Why? Because it is xml and the root element is xhtml. It would also
be correct to label it xml-- but that should only be done if you can't further
recognize it as an xhtml file.
It should not be recognized as an svg file, it is a compound file that embeds
an svg
> XML (goes to my xml editor), XHTML (goes to my browser) or SVG
> (goes to my vector graphics editor)?
WOW, talk about a mixture of concerns--
So what should be able to open it?
text editor, text viewer
xml editor, xml viewer
html editor, browser (html viewer)
svg editor, svg viewer
If you have this xpath enabled filesystem you're talking about,
then the finder should be able to open it too.
maybe some others.
Now what actually should open it when you double click on it--
or furthermore, how should that be decided?
Obviously the decision should belong to the user of the shell. It may
be decided ahead of time and stored as some sort of preference.
Where should the preference be kept? As meta data of the file? or meta
data of the shell user?
>
> MacOS got it right in separating type from name. POSIX got it dead
Indeed OS9 had it right. POSIX may have it wrong, but they do better than
file extentions. The problem with explicit meta-data, including file
extensions for that matter, is that it can lie-- and you get profound failure
as the mp3 demonstration above shows.
> NOTE: even web servers that mount one2one the URL space to the FS space
> share the exact same design mistakes. The Cocoon2 sitemap was
> introduced exactly to solve those problems.
I agree with this.
>
> The problem is much more complex than you outlined.
Of course it is.
Tim
Re: Mime-Types
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Jul 16, 2003, at 12:24 America/Guayaquil, Tim Myers wrote:
> Hey Stefano,
>
> Don't you use Mac OS X now? You know what apple really got wrong in
> the
> finder? They use file extentions!!!
I think this is not the case.
> OS9- had file attributes to store typing
> information.
I believe this is true for OSX as well.
> That has it's advantages and disadvantages- Unix has this
> perfectly wonderful system for typing, /usr/bin/file and /etc/magic.
hmmm, a matadata inference system is a good help against lazyness, but
it's never as effective as explicit metadata. IMHO, POSIX falls short
in that domain and UNIX just tried to work around it with automagic
type discovery (which <?xml version="1.0"?> shows it can be a massive
mistake!)
> Apple
> moved to unix and the finder doesn't use this system!?!
OSX Finder (and the 'open' terminal command) uses FS metadata to know
which application is associated to a given file, not extensions.
> Here's a fun exersize.
>
> Take an mp3, post it someplace (ftp, http) download it to your home
> directory
> on a mac and do the same in linux. Double click it in the finder on
> the mac;
> in Nautilus on linux. It will play.
>
> Here's the fun part. Rename that file song.mp3 to song.zip. Download
> it
> again. Double click.
If your download is on HTTP, the wrong mime type is probably given by
your web server. In this case, this is not OSX fault at all! It's your
web servers!
[in case of FTP, there is no MIME-type associated to the file. One of
the many reason not to use FTP]
> It shouldn't be a filesystem module poking into the file trying to
> guess it's
> type-- that should be beyond the scope of the file system.
I disagree. This module should kick in only if no type metadata is
available, but 'poking into the file' might be an increasingly
difficult exercise and might yield unwanted results.
If you have an XHTML page with some inlined SVG, what MIME type is
that? XML (goes to my xml editor), XHTML (goes to my browser) or SVG
(goes to my vector graphics editor)?
MacOS got it right in separating type from name. POSIX got it dead
wrong (and Reiser shows that better design with elegance and simplicity
IS possible) and UNIX implementations tried to work around it with
autodiscovery.
Which, IMO, in the next few years of XML expansion, will show how
crappy the approach is.
NOTE: even web servers that mount one2one the URL space to the FS space
share the exact same design mistakes. The Cocoon2 sitemap was
introduced exactly to solve those problems.
So, IMO, Cocoon and ReiserFS go hand in hand in improving what it was
previously defective in design, the first for URL space and the second
for FS space. [I heard that even the next version of windows, longhorn,
will have a similar approach implementing an object-oriented file
system based on top of parts of sqlserver]
> It should be the
> shell using a command like file that figures out syntactically and
> symantically
> what the file is and what it can do with it.
Disagree. MacOS approach is, IMO, much better and doesn't yield
inconsistent results. Automatic discovery should kick in only where
there is no type metadata available and provide a list of options to
the user as to what type it can be if more than one match... even if,
with XML this could become a real problem, expecially once they are
sent gzipped like in openoffice case or compressed SVG)
The problem is much more complex than you outlined.
--
Stefano.
Mime-Types
Posted by Tim Myers <ph...@pirouline.sts.jhu.edu>.
Hey Stefano,
Don't you use Mac OS X now? You know what apple really got wrong in the
finder? They use file extentions!!! OS9- had file attributes to store typing
information. That has it's advantages and disadvantages- Unix has this
perfectly wonderful system for typing, /usr/bin/file and /etc/magic. Apple
moved to unix and the finder doesn't use this system!?!
Here's a fun exersize.
Take an mp3, post it someplace (ftp, http) download it to your home directory
on a mac and do the same in linux. Double click it in the finder on the mac;
in Nautilus on linux. It will play.
Here's the fun part. Rename that file song.mp3 to song.zip. Download it
again. Double click.
It shouldn't be a filesystem module poking into the file trying to guess it's
type-- that should be beyond the scope of the file system. It should be the
shell using a command like file that figures out syntactically and symantically
what the file is and what it can do with it.
Tim
On Tue, Jul 15, 2003 at 03:03:20PM -0500, Stefano Mazzocchi wrote:
>
> On Tuesday, Jul 15, 2003, at 13:49 America/Guayaquil, Tony Collen wrote:
>
> > Stefano Mazzocchi wrote:
> >
> > <snip-cool-stuff/>
> >
> >> changes the content of the node! right from the command line. You can
> >> use symlinks to share content between your document!!! you can have
> >> ACL at the node level!!! just write an xgrep and you are able to do
> >> xpath searches from the command line! just add an XML parser and you
> >> are able to do something like
> >> cat xhtml.dtd > /document/@schema
> >> and when you save your stuff as /document, the file system will
> >> trigger an error if the file is not valid!
> >> Imagine all the stuff that you can do with this! and the file system
> >> can be journalled, offer node-level transactional capabilities, you
> >> name it! at right into the OS. fast fast fast!
> >
> > This is all really cool.. the only thing is that it assumes that all
> > files are XML.
>
> NO! that's the beauty
>
> echo "application/xml" > /document/@mime-type
>
> Voila' ;-)
>
> Actually, even better
>
> echo "xml" > /document/@syntax
> echo "text/xhtml" > /document/@mime-type
>
> because MIME is getting it all wrong with this stupid +xml by mixing
> concerns between the syntax and the semantics.
>
> Do you see the potential?
>
> > The obvious question is what happens when you try to do an xpath
> > expression on a file that is not XML. Perhaps the filesystem module
> > would know enough to check for <?xml version="1.0"?> ?
>
> ARRRRRGGGG!
>
> >
> > Lots of potential though :) Maybe you could tie a service to a
> > virtual device. Like /dev/xupdate or /dev/xalan, and output to > STDOUT?
> >
>
> That's much better talking, bro ;-)
>
> --
> Stefano.
Re: [RT] The perfect repository might be just under your eyes
Posted by Santiago Gala <sg...@hisitech.com>.
Tony Collen escribió:
> Stefano Mazzocchi wrote:
>
>> NO! that's the beauty
>>
>> echo "application/xml" > /document/@mime-type
>>
>> Voila' ;-)
>>
>> Actually, even better
>>
>> echo "xml" > /document/@syntax
>> echo "text/xhtml" > /document/@mime-type
>>
>> because MIME is getting it all wrong with this stupid +xml by mixing
>> concerns between the syntax and the semantics.
>>
>> Do you see the potential?
>>
>>> The obvious question is what happens when you try to do an xpath
>>> expression on a file that is not XML. Perhaps the filesystem module
>>> would know enough to check for <?xml version="1.0"?> ?
>>
>>
>>
>> ARRRRRGGGG!
>>
>>>
>>> Lots of potential though :) Maybe you could tie a service to a
>>> virtual device. Like /dev/xupdate or /dev/xalan, and output to >
>>> STDOUT?
>>>
>>
>> That's much better talking, bro ;-)
>
>
> More RTing:
>
> Imagine having an XSL processor in the kernel:
>
> You could "execute" .xsl files, bypassing having to run a processor
> manually.
>
> prompt$ page2html.xsl < input.xml > output.html
>
> Borrowing the pipeline concept from Cocoon:
>
> prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl >
> output.html
>
> One could even invent files which are actually transformation pipelines
> -- ones which you might not be able to directly edit (or maybe be able
> to edit a transformation in the middle):
>
> prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
>
Itn't it kind of:
export ACCEPT="es_ES;1.0, en;0.9, *;0.1"
# more environment here
./sitemap.xmap output.html
I mean, the sitemap is like a "restricted shell" used to specify
transformation chains. As HTTP is request-response, in Cocoon you give
it is the sitemap, the output requested and some ENV vars ;-). With a
true shell, more freedom would be needed/granted.
In any case, the material here is great for a tutorial on "cocoon for
unix-geeks".
The flow is a bit different. A classic shell has the processing
pipelines specification + logics mixed together, while in Cocoon these
are specified as different concerns. After all, bash is a tool for
programmers, while cocoon has several isolated concerns in a data
processing + publishing environment.
> Now you can just go
>
> prompt$ cat virtual.xml
>
> And get the output of the pipeline defined above, which you can then
> link to other pipelines, etc.
>
> It's no wonder that this all fits in very well with what Cocoon does,
> since Cocoon is patterned after this concept. I'm sure if I stew on
> this concept enough I'll come up with more ideas and uses.
>
> Tony
>
Regards
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
Re: [RT] The perfect repository might be just under your eyes
Posted by Karel Vervaeke <ka...@pandora.be>.
Tony Collen wrote:
> Stefano Mazzocchi wrote:
>
>> NO! that's the beauty
>>
>> echo "application/xml" > /document/@mime-type
>>
>> Voila' ;-)
>>
>> Actually, even better
>>
>> echo "xml" > /document/@syntax
>> echo "text/xhtml" > /document/@mime-type
>>
>> because MIME is getting it all wrong with this stupid +xml by mixing
>> concerns between the syntax and the semantics.
>>
>> Do you see the potential?
>>
>>> The obvious question is what happens when you try to do an xpath
>>> expression on a file that is not XML. Perhaps the filesystem module
>>> would know enough to check for <?xml version="1.0"?> ?
>>
>>
>>
>> ARRRRRGGGG!
>>
>>>
>>> Lots of potential though :) Maybe you could tie a service to a
>>> virtual device. Like /dev/xupdate or /dev/xalan, and output to >
>>> STDOUT?
>>>
>>
>> That's much better talking, bro ;-)
>
>
> More RTing:
>
> Imagine having an XSL processor in the kernel:
>
> You could "execute" .xsl files, bypassing having to run a processor
> manually.
>
> prompt$ page2html.xsl < input.xml > output.html
making the above line work would be a piece of cake.
You can make (just about) anything executable: see
documentation/java.txt in the kernel about making .class files
executable. For .class files it's based on the CAFEBABE header - xsl is
- roughly speaking - just around the corner when you get the hex
equivalent of <?xml version="1.0"?> :)
http://www.google.com/search?q=xmlfs <-- people have thought about this
before :)
>
>
> Borrowing the pipeline concept from Cocoon:
>
> prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl >
> output.html
>
>
> One could even invent files which are actually transformation
> pipelines -- ones which you might not be able to directly edit (or
> maybe be able to edit a transformation in the middle):
>
> prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
>
> Now you can just go
>
> prompt$ cat virtual.xml
>
> And get the output of the pipeline defined above, which you can then
> link to other pipelines, etc.
>
> It's no wonder that this all fits in very well with what Cocoon does,
> since Cocoon is patterned after this concept. I'm sure if I stew on
> this concept enough I'll come up with more ideas and uses.
>
> Tony
>
>
>
>
Re: [RT] The perfect repository might be just under your eyes
Posted by Tim Myers <ph...@pirouline.sts.jhu.edu>.
Hi guys.
> Imagine having an XSL processor in the kernel:
I don't think you are asking for xsl in the kernel. What you are asking for is
the cocoon shell: cocoonsh. Also, though it would be theoretically possible to
implement an xml aware filesystem-- Some experience (google search xdelta xdfs)
has shown that a usermode filesystem extension (i.e. cocoonfs)
may be more convenient. And if you want that mapped to a mountable filesystem
in linux, use a thing like podfuk <http://uservfs.sourceforge.net/>.
The most useful thing the coda project has come up with is a simple filesystem
hook into linux: /dev/coda. Podfuk is a great usecase.
The possibilities are amazing.
Tim
> You could "execute" .xsl files, bypassing having to run a processor manually.
>
> prompt$ page2html.xsl < input.xml > output.html
>
> Borrowing the pipeline concept from Cocoon:
>
> prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl > output.html
>
> One could even invent files which are actually transformation pipelines -- ones which you might not
> be able to directly edit (or maybe be able to edit a transformation in the middle):
>
> prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
>
> Now you can just go
>
> prompt$ cat virtual.xml
>
> And get the output of the pipeline defined above, which you can then link to other pipelines, etc.
>
> It's no wonder that this all fits in very well with what Cocoon does, since Cocoon is patterned
> after this concept. I'm sure if I stew on this concept enough I'll come up with more ideas and uses.
>
> Tony
>
RE: [RT] The perfect repository might be just under your eyes
Posted by Robert Koberg <ro...@koberg.com>.
Hmmm... makes me think of XSL's document function....
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Tuesday, July 15, 2003 1:53 PM
> To: dev@cocoon.apache.org
>
>
> On Tuesday, Jul 15, 2003, at 15:40 America/Guayaquil, Tony Collen wrote:
>
> > More RTing:
> >
> > Imagine having an XSL processor in the kernel:
> >
> > You could "execute" .xsl files, bypassing having to run a processor
> > manually.
> >
> > prompt$ page2html.xsl < input.xml > output.html
> >
> > Borrowing the pipeline concept from Cocoon:
> >
> > prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl >
> > output.html
> >
> > One could even invent files which are actually transformation
> > pipelines -- ones which you might not be able to directly edit (or
> > maybe be able to edit a transformation in the middle):
> >
> > prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> > --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
> >
> > Now you can just go
> >
> > prompt$ cat virtual.xml
> >
> > And get the output of the pipeline defined above, which you can then
> > link to other pipelines, etc.
> >
> > It's no wonder that this all fits in very well with what Cocoon does,
> > since Cocoon is patterned after this concept. I'm sure if I stew on
> > this concept enough I'll come up with more ideas and uses.
>
> It might be a good mental exercise, but before you do, please remember
> that UNIX has no notion of structured pipelines as Cocoon does. That
> is, you will always need a serialization/parsing stage between
> different filters, which is instrinsically poor.
>
> Also, consider that there is no type safety since all components are
> the same (unlike in cocoon where you can't have a transformer after a
> serializer).
>
> So, keep in mind the differences.
>
> --
> Stefano.
Re: [RT] The perfect repository might be just under your eyes
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Jul 15, 2003, at 15:40 America/Guayaquil, Tony Collen wrote:
> More RTing:
>
> Imagine having an XSL processor in the kernel:
>
> You could "execute" .xsl files, bypassing having to run a processor
> manually.
>
> prompt$ page2html.xsl < input.xml > output.html
>
> Borrowing the pipeline concept from Cocoon:
>
> prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl >
> output.html
>
> One could even invent files which are actually transformation
> pipelines -- ones which you might not be able to directly edit (or
> maybe be able to edit a transformation in the middle):
>
> prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
>
> Now you can just go
>
> prompt$ cat virtual.xml
>
> And get the output of the pipeline defined above, which you can then
> link to other pipelines, etc.
>
> It's no wonder that this all fits in very well with what Cocoon does,
> since Cocoon is patterned after this concept. I'm sure if I stew on
> this concept enough I'll come up with more ideas and uses.
It might be a good mental exercise, but before you do, please remember
that UNIX has no notion of structured pipelines as Cocoon does. That
is, you will always need a serialization/parsing stage between
different filters, which is instrinsically poor.
Also, consider that there is no type safety since all components are
the same (unlike in cocoon where you can't have a transformer after a
serializer).
So, keep in mind the differences.
--
Stefano.
Re: [RT] The perfect repository might be just under your eyes
Posted by Tony Collen <co...@umn.edu>.
Stefano Mazzocchi wrote:
> NO! that's the beauty
>
> echo "application/xml" > /document/@mime-type
>
> Voila' ;-)
>
> Actually, even better
>
> echo "xml" > /document/@syntax
> echo "text/xhtml" > /document/@mime-type
>
> because MIME is getting it all wrong with this stupid +xml by mixing
> concerns between the syntax and the semantics.
>
> Do you see the potential?
>
>> The obvious question is what happens when you try to do an xpath
>> expression on a file that is not XML. Perhaps the filesystem module
>> would know enough to check for <?xml version="1.0"?> ?
>
>
> ARRRRRGGGG!
>
>>
>> Lots of potential though :) Maybe you could tie a service to a
>> virtual device. Like /dev/xupdate or /dev/xalan, and output to > STDOUT?
>>
>
> That's much better talking, bro ;-)
More RTing:
Imagine having an XSL processor in the kernel:
You could "execute" .xsl files, bypassing having to run a processor manually.
prompt$ page2html.xsl < input.xml > output.html
Borrowing the pipeline concept from Cocoon:
prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl > output.html
One could even invent files which are actually transformation pipelines -- ones which you might not
be able to directly edit (or maybe be able to edit a transformation in the middle):
prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
--tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
Now you can just go
prompt$ cat virtual.xml
And get the output of the pipeline defined above, which you can then link to other pipelines, etc.
It's no wonder that this all fits in very well with what Cocoon does, since Cocoon is patterned
after this concept. I'm sure if I stew on this concept enough I'll come up with more ideas and uses.
Tony
Re: [RT] The perfect repository might be just under your eyes
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Jul 15, 2003, at 13:49 America/Guayaquil, Tony Collen wrote:
> Stefano Mazzocchi wrote:
>
> <snip-cool-stuff/>
>
>> changes the content of the node! right from the command line. You can
>> use symlinks to share content between your document!!! you can have
>> ACL at the node level!!! just write an xgrep and you are able to do
>> xpath searches from the command line! just add an XML parser and you
>> are able to do something like
>> cat xhtml.dtd > /document/@schema
>> and when you save your stuff as /document, the file system will
>> trigger an error if the file is not valid!
>> Imagine all the stuff that you can do with this! and the file system
>> can be journalled, offer node-level transactional capabilities, you
>> name it! at right into the OS. fast fast fast!
>
> This is all really cool.. the only thing is that it assumes that all
> files are XML.
NO! that's the beauty
echo "application/xml" > /document/@mime-type
Voila' ;-)
Actually, even better
echo "xml" > /document/@syntax
echo "text/xhtml" > /document/@mime-type
because MIME is getting it all wrong with this stupid +xml by mixing
concerns between the syntax and the semantics.
Do you see the potential?
> The obvious question is what happens when you try to do an xpath
> expression on a file that is not XML. Perhaps the filesystem module
> would know enough to check for <?xml version="1.0"?> ?
ARRRRRGGGG!
>
> Lots of potential though :) Maybe you could tie a service to a
> virtual device. Like /dev/xupdate or /dev/xalan, and output to > STDOUT?
>
That's much better talking, bro ;-)
--
Stefano.
Re: [RT] The perfect repository might be just under your eyes
Posted by Tony Collen <co...@umn.edu>.
Stefano Mazzocchi wrote:
<snip-cool-stuff/>
> changes the content of the node! right from the command line. You can
> use symlinks to share content between your document!!! you can have ACL
> at the node level!!! just write an xgrep and you are able to do xpath
> searches from the command line! just add an XML parser and you are able
> to do something like
>
> cat xhtml.dtd > /document/@schema
>
> and when you save your stuff as /document, the file system will trigger
> an error if the file is not valid!
>
> Imagine all the stuff that you can do with this! and the file system can
> be journalled, offer node-level transactional capabilities, you name it!
> at right into the OS. fast fast fast!
This is all really cool.. the only thing is that it assumes that all files are XML. The obvious
question is what happens when you try to do an xpath expression on a file that is not XML. Perhaps
the filesystem module would know enough to check for <?xml version="1.0"?> ?
Lots of potential though :) Maybe you could tie a service to a virtual device. Like /dev/xupdate
or /dev/xalan, and output to STDOUT?
Just rattling off goofy ideas.
Tony
Re: [RT] The perfect repository might be just under your eyes
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Jul 16, 2003, at 09:01 America/Guayaquil, Niclas Hedhman
wrote:
>
> What you are trying to say (I think) is that the FS needs the whole
> XPath
> spec, not only ways to treat XML documents as filestructures, right?
Right on, bro.
--
Stefano.
Re: [RT] The perfect repository might be just under your eyes
Posted by Niclas Hedhman <ni...@hedhman.org>.
All very funny and well thought of, but since noone else throws sand in
your machinery, let me... (as usual).
Stefano wrote;
> But think about it:
>
> /document
>
> is the full document
>
> /document/html/body/p
>
> is the content of the p node, so
>
> echo "whatever" > /document/html/body/p
>
> changes the content of the node! right from the command line. You can
> use symlinks to share content between your document!!! you can have ACL
> at the node level!!! just write an xgrep and you are able to do xpath
> searches from the command line! just add an XML parser and you are able
> to do something like
So I have in the node 'body' the following nodes;
p
p
p
p
p
p
p
p
p
Which node gets the "whatever" in your example above?
What you are trying to say (I think) is that the FS needs the whole XPath
spec, not only ways to treat XML documents as filestructures, right?
But I must admit. Very ELEGANT per se, and shows how much an incredible
design (FileSystem) can be stretched, 30-40 years into the future.
Niclas
Re: [RT] The perfect repository might be just under your eyes
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Stefano Mazzocchi wrote:
> I admit that I thought that POSIX was so carved in stone that I never
> even considered extending it to provide the functionality that was
Hehe, this can happen if you are too prejudiced to something, but at
least you realized that it is not so ;-)
I also read about ReiserFS (must be one or two years ago) and use it
since that time on my Linux box with good experiences.
This is also the case for LVM (http://www.sistina.com/products_lvm.htm)
which newer Linux distributions include, but I think this is offtopic here.
> Imagine all the stuff that you can do with this! and the file system can
> be journalled, offer node-level transactional capabilities, you name it!
> at right into the OS. fast fast fast!
... and it offers great flexibility and extensibility.
ReiserFS offers the possibility to store any metadata you need for a node.
> What? it's not remote, you say? get over it: scp and duct tape can make
> it as remote as anything.
>
> Forget WebDAV, forget JSR170, your perfect repository might be, thanks
I wouldn't be so harsh to say, that you can forget about WebDAV and
JSR170, but in some cases this may be completely true!
> to the pseudo-file concept, just a new linux module away.
Perhaps you don't even need a module, since at least SuSE Linux already
uses ReiserFS as the standard FS for a long time.
> --
> Stefano.
>
Bye,
Andreas Hochsteger
http://highstick.blogspot.com/