[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Is XML getting too hard?

• From: "Jonathan Borden" <jborden@m...>
• To: "XML Dev" <xml-dev@i...>
• Date: Tue, 18 Aug 1998 16:15:03 -0400

>
>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@m...





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

• Prev by Date: Re: DOM Node.cloneNode()
• Next by Date: XSchema Specification - Extensions (Section 2.6), Draft 3
• Previous by thread: DOM Node.cloneNode()
• Next by thread: XSchema Specification - Extensions (Section 2.6), Draft 3
• Index(es):
  • Date
  • Thread