OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Interoperability



From: "James Clark" <jjc@jclark.com>
 
> OpenOffice is also using ZIP as a packaging format for XML. See
> 
>   http://xml.openoffice.org/faq.html#4

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.

Cheers
Rick Jelliffe

(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. )