RE: No more W3C plans to address packaging

My simple goals for xml packaging would be to promote server side modularity
of any xml and non-xml documents, specifically to achieve a unit of
modularity higher than an XML file, perhaps a "xar" file.

We constantly run into issues of how to re-use compound xml documents.

While I do tend to like XInclude for a variety of use cases, I'm not sure
about the applicability to xml packaging.  In particular, it is difficult to
create URIs that would work across packaged and non-packaged solutions.
Imagine file X including file y.  What should the URI look like?  If you use
file: is used, then how should an XML parser know to look inside a XAR file
versus in the file system?  And what about mixing files in packages with
files not in packages.

It is very interesting how Java solved this through the intermediary notion
of separate class path with import statements.  Perhaps an "XInclude" URI
path is needed for an XML Parser.  Lessons from Java classpaths and war
files are probably appropriate in this space.

I believe that the transparency of the data model of XML and of URIs may
conspire to make the goal of packaging XML very difficult.  This is showing
up already in problems of containment models of XP nee SOAP.

Cheers,
Dave Orchard

> -----Original Message-----
> From: www-xml-packaging-request@w3.org
> [mailto:www-xml-packaging-request@w3.org]On Behalf Of Robin Berjon
> Sent: Wednesday, November 01, 2000 7:48 PM
> To: Simon St.Laurent
> Cc: www-xml-packaging@w3.org
> Subject: Re: No more W3C plans to address packaging
>
>
> At 13:11 31/10/2000 -0500, Simon St.Laurent wrote:
> >>>I think much of the community is aware of this development,
> >>>but just to close the loop...
> >>
> >>Is anyone in the community interested in picking up the ball ?
> >I certainly would be, but we've got to figure out what
> exactly packaging is.
>
> I'd be too, and the question(s) you ask is precisely the reason why I
> wanted to know if anyone was working on xml packaging.
>
> "Packaging" can mean a lot of things. I haven't yet had time
> to look into
> the other packaging initiaves that were mentionned on this
> list so I don't
> know exactely what angle they approach packaging from.
>
> The angle I'm interested in is geared towards having a bunch
> of files --
> XML or not -- somehow bundled into an XML document (stored within and
> encoded or stored outside). In fact some sort of XML file
> system. Some time
> ago I read about Microsoft using a "micro" file system within
> Office in
> order to store multiple documents of any type within one
> single file. I
> think it was called OLE-FS but I'm not sure, and as the
> saying goes if you
> don't like the name Microsoft gave to one of it's
> products/functions just
> wait five minutes (I couldn't find a reference to that on their site).
>
> I'm interested in developing an XML vocabulary that would be
> able to store
> documents either by value (with different encodings that can
> be specified)
> or by reference (probably using something like XInclude) including
> directories (so that a file system can be directly mapped into that
> vocabulary) and other metadata such as permissions or
> resource forks, the
> metadata being extensible so as to allow any data to be
> grafted onto the
> files. RDF could be a way to encode such information, it
> tends to scare
> people away but it seems appropriate given that what I have in mind is
> could be summarized as a grouping of resources (by value or
> by reference)
> together with arbitrary metadata about them.
>
> Such schemes are already used here and there, in XML or not
> but I have yet
> to see one that does all of this and allows for extensibility
> (I haven't
> looked into the OpenOffice initiative yet).
>
>
> -- robin b.
> Smoking is one of the leading causes of statistics.
>

Received on Friday, 3 November 2000 03:29:44 UTC