Presumably you would need to have an equivalent of a .jar manifest, which allows you to specify what files fulfil what functions - could this be done with some variant on a RDDL document?
The way things are packaged up (the internal directory structure) would seem to be a wondersful candidate for what could essentially be hierarchical namespacing (thinking here of the idea of codebases in html which point to a URL where the dzip file could be found). Or is that opening another barrel of worms (fruitful or otherwise)?
The XML Management Company
+31 (0)20 750 7582 / +31 (0)6 65 347 448 / www.barbadosoft.com
- putting the "X" in "XML" -
From: Rick Jelliffe [mailto:firstname.lastname@example.org]
Sent: 16 November 2001 11:00
Subject: Re: [xml-dev] Interoperability
From: "James Clark" <email@example.com>
> OpenOffice is also using ZIP as a packaging format for XML. See
Also see http://xml.openoffice.org/package.html
But the Open Office package format is concerned with packaging documents,
which I would avoid like the plague.
> I think a ZIP-based packaging format makes a lot of sense, but getting all
> the details right is non-trivial. An OASIS TC would be a natural place to
> standardize this given the overlap with entity resolution catalogs.
Yes, and there is already an OASIS group on Entity Resolution which is a related
area. I am interested in knowing what issues people think are important
here: as the simplest case, would merely saying "Just stick files with well-known
extensions in a ZIP file with certain naming conventions to handle versioning"
actually be all we need for a workable approach (i.e., if toolmakers would
all support looking into ZIP files for DTDs and related resources)?
But even if there is an OASIS group that specs it, would vendors get on
board? Or would it expose that while they are happy to have document exchange
using XML being flexible, but not so happy if it is easy to change applications
(and therefore to change products)? Actually, I don't believe that XML
tools-vendors are at all happy that setting up applications can be such
a major task, nor that they can be difficult to maintain (i.e. with XML one
gets a lot of flexibility in the different products we can connect together,
but once we have done the work to connect them it is still a big thing
to change or update them.) But they would not be expected to move in
this area until there is a level of user demand or until they reach the stage
in their business where deployability and maintainability become important
selling issues. The more that XML products are easy to configure and
update, the more that they can be successful on the desktop as well
as the back-end.
(For the equity angle on this, perhaps we can ask the question
"How can we move XML away from being a tool of the large
corporates and toward being something useful for encouraging
a technical middle class in poorer countries who
can integrate systems for local businesses?" Unless there is
an XML application deployment solution for dummies, to
some extent XML is part of the problem. Horrifically that
makes the Microsoft approach of encouraging integrators
part of the solution, but there we go. )
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