Another €0.02 worth:
XAR/DZIP/[insertYourFavouriteAcronymHere] also seems to offer a simple mechanism for producing and managing "builds" of different versions of a system. We are addressing the problems of versioning large schema families and their associated (XML or non-XML) bits, and we'd love to see a "standard" and robust deployment mechanism to support the necessary development methodology - you can only go so far with socat. Just for starters, it seems to have the potential to cut out a lot of search-and-replace when schema versions change, by allowing multiple versions of schema fragments to have the same URI or namespace identifier (from the point of view of referencing entities), making finer granularity reuse and modularization way more manageable.
What I'd also vote to see in there would be something akin to a classpath mechanism, which would help externalize inclusion of 3rd party resources and make it easy to switch between libraries.
John
_______________________________________________________
John Anderson
CTO BarbadosoftTM
The XML Management Company
+31 (0)20 750 7582 / +31 (0)6 65 347 448 / www.barbadosoft.com
- putting the "X" in "XML" -
-----Original Message-----
From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
Sent: 16 November 2001 17:15
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Interoperability
On Friday 16 November 2001 01:28 am, Rick Jelliffe wrote:
> 3) Packaging
> ----------------
> The other mechanism, and the one I think we need,
> is a simple file format for packaging all the resources
> for generic and value-added XML applications: an
> XML application archive format (XAR Gavin has
> suggested.) The kind of thing I am suggesting
> can be found at http://www.topologi.com/public/dzip.html
FWIW. When Rick pointed me at the dzip page, the value was immediately
obvious to me.The notion of XAR came from recognising that ZIP formats like
this are the defacto standard for JAVA packaging, and they have lot's of
wonderful properties:
1) The nicely avoid all the MIME nastiness with regards packing of textual
content.
2) They already support the notion of package-metadata via the META-INF
directory.
3) They can be compressed.
4) They can be made secure, by, for example, encrypting all the ZIP content
and then providing the public key in the META-INF folder.
etc. etc. etc.
I think this is something we (as a community) should heartily embrace.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>