Is XML getting too hard?

[Jonathan Borden]

>
>The idea of bundling up many files - promoted by David Megginson - is an
>exciting one. If I could be assured that I could send a jar file to a
>client and they could unbundle it seamlessly and effortlessly then I might
>very well eschew the complexities of namespaces (I'd still use simple
>ones). Effectively each namespaced object would be a file with a unique
>namespace. These could be referenced from the document either as NDATA (am
>I right?) or by XLink.
>
> However I am not convinced that this is a good idea for storing files
>client-side or manipulating them locally. Either they would remain as *.jar
>- which are unreadable by humans - or they would be expanded to lots of
>little files which could very easily get lost or overwritten. My own
>suggestion would be for a 'multipart' file where the different XML
>components were concatenated - perhaps even by special syntax. Then they
>are both human-readable and physically bound.

    multipart/related works well. Each part gets a Content-ID label which
translates into a "cid:xxx" URI. This allows each part to be internally
linked. The other advantage is that different parts can have different
Content-Types so that binary data can interoperate with XML. This is
especially true if an overall DOM is developed with integrates XML and other
datatypes.


Jonathan Borden
JABR Technology Corporation
jborden at mediaone.net





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)