Re: [xml-dev] XPackage: RDF/XLink-based packaging format

I support the view that packaging and manifest-like things are quite 
different and shouldn't be done with the same mechanism.  If fact, I 
have a criteria that I think clearly separates these two:

A trivial package should be a set of files within a directory.  A 
more sophisticated packaging mechanism can turn these into a single 
file, preferably with an API that allows accessing the content files 
without unpackaging. There should be nothing in the packaging 
mechanism that cannot also be represented within the normal file 
systems.  Any additional information should be just yet another file 
in the group.

At 7:12 AM -0800 11/26/01, Garret Wilson wrote:
>Rick,
>
>----- Original Message -----
>From: "Rick Jelliffe" <ricko@allette.com.au>
>To: "xml-dev list" <xml-dev@lists.xml.org>
>Cc: "www-xml-packaging list" <www-xml-packaging@w3.org>
>Sent: Monday, November 19, 2001 8:52 PM
>Subject: Re: [xml-dev] XPackage: RDF/XLink-based packaging format
>
>
>  > XPackage looks like it would be a suitable and comprehensive packaging
>format to use
>  > in XAR (a mooted XML Application Archive format).
><cut/>
>  >  2) XPackage does not specify any "physical bundling mechanism".
>  >
>  >   DZIP specifies a particular physical bundling mechanism: ZIP/JAR.
>
>The original W3C XML Packaging WG charter apparently tried to mix two parts
>of packaging: the description of the packaged resources and their
>relationships, and the physical bundling of those resources into a binary
>file. I consider both of those issues extremely valuable and necessary, but
>XPackage addresses only the former.
>
>XPackage has multiple descriptive uses: the metadata/manifest part of a
>physical compression/encryption format as you mentioned; a small snippet of
>description of resources to be passed in the body of a SOAP message; a more
>generalized and extensible solution for specifying purposes and natures and
>a replacement for RDDL, just to name a few.
>
>  >    DZIP has a low buy-in: just look in well-known directories of the
>  >    archive for files with well-known extensions.  A person who wants to
>  >    create an XAR should only need to use WinZIP with no metadata
>  >     required. There is no need to support internal versions or fallback.
>
>I've advocated Zip files for short-term solution to the physical archive
>problem. My company, GlobalMentor, distributes its eBooks in OEBZip
>files---simply Zip files containing raw OEB files. The benefits of using Zip
>for .jar, .war, and .ear files are obvious.
>
>There are problems with Zip as a long-term solution, however. Zip doesn't
>natively support Unicode filenames. Zip's native encryption is weak. The
>shortcomings of Zip are outlined at http://www.dlugosz.com/ZIP2/ and even
>InfoZip has outlined at ftp://ftp.info-zip.org/pub/infozip/FAQ.html#limits
>the requirements for a new version of Zip that gets around such limits as
>Zip's 4GB limit.
>
>XPackage, though, is agnostic to the physical archiving format used, and it
>should be. XPackage could be used with DZIP, Zip, Jar, or any other physical
>packaging scheme. Such a standard description file is needed---the current
>use of the manifest used in a Jar META-INF directory, for example, is a
>kludge, is proprietary, and isn't easily exstensible (note the diverse
>additional description files required in a Jar file to specify default XML
>processors).
>
>  > Given those very limited aims of XAR, XPackage is overkill and I think
>  > DZIP has clear advantages of straightforwardness and convenience.
>
>As I described above, I believe the two specifications are meeting different
>needs: package description (XPackage) and package archiving (DZIP), although
>DZIP tries to force some limited relational information into the structure
>of the archive (see filename restrictions in DZIP point 7). DZIP moreover
>allows package description in its root through RDDL, for example. Whatever
>description is present in an archive needs to be refactored, generalized,
>and standardized, which is exactly what XPackage attempts to do.
>
>  > However, DZIP is not incompatible with XPackage. Any DZIP archive could
>  > have an XPackage description document, just as it could have a RDDL
>  > directory and SOCAT catalog.  In fact, an automated tool could be
>  > constructed to create the XPackage description document for any
>  > particular DZIP archive.
>
>Exactly, although DZIP by itself is semantically poor which upon conversion
>would result in a semantically poor XPackage file. (This is analogous to
>converting from a PDF file to an XML document).
>
>  > Actually, I am assuming that DZIP is not incompatible with XPackage.
>  > The RDF seems to let one say that "this is the XSLT stylesheet for that
>  > XML document" but it is not clear to me how it can say "this is the XSLT
>  > stylesheet for the future XML documents that use this XAR"
>  > Can I use XPackage for that?
>
>You can create a resource description representing the package as an entity,
>and associate a stylesheet with that.  We would need to discuss the
>specifics of this use case to know whether this needs to be made more
>explicit by adding a property that specifies that a stylesheet property
>should be applied to a resource's children as well.
>
>Garret


Jim King
Adobe Systems Incorporated

Received on Monday, 26 November 2001 17:11:01 UTC