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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Multimedia package patterns possibly relevant to packaging issues


I think that, over time, we will want to use different mechanisms for the
outer wrapper of a message, specifically a MIME wrapper or an XML wrapper.

Ideally though we need a way to identify the constituent parts of a message
that is independent of the method used in the external wrapper so that we
don't need to change our specification as we develop new wrappers.

Looking at the first URL you gave below, it uses the idea of a "cid" to
identify the Mime part that is being reference. The use of "cid" for content
id is "MIME centric" which is fine for MIME, but less so if the outer
wrapper was XML. If we can't develop a common approach then, in the Message
Manifest we will probably include in the header, we might be left with:

A MIME/CID approach:
   <DocumentReference Id='AB273' DocumentType='Text/XML'
      Purpose='MessageRoutingInfo' >

An XML/IDREF approach
   <DocumentReference Id='AB273' DocumentType='Text/XML'
      Purpose='MessageRoutingInfo' >

My inclination (although i'd appreciate your views) is to go for a URI based
approach which would look like:
   <DocumentReference Id='AB273' DocumentType='Text/XML'
      Purpose='MessageRoutingInfo' >

... and then say ...
1. For MIME, the URI matches the Content ID of a MIME part
2. For XML, it matches an ebXML:name attribute on the root

... but I'm not sure this is the right way to go.



-----Original Message-----
From: Dale Moberg [mailto:Dale_Moberg@stercomm.com]
Sent: Thursday, March 09, 2000 10:44 AM
To: ebXML Transport (E-mail)
Subject: Multimedia package patterns possibly relevant to packaging


A good initial overview is found at
In particular, compare listing3
(all xml with some external referencing)
to listing4 (multipart/related using cid URNs).
(SMIL examples)

Then look at

To speed things up, jump to Appendix C.2,
"Use of external entities and MIME packaging"

Also, some interesting technical points
that I think are relevant to packaging:
1. A pure XML doc does not have to have everything
"inline"-- that is, within a sinle sequence of
 characters (utf-8 or whatever). Lots of
kinds of entities, including the unparsed
2. XML APIs include both DOM and SAX.
 For SAX style parsers,
it is not necessary to build a
complete parse tree before doing
something. SAX parsers work by
registering "events" (like seeing a new
element start tag) and then checking
for "handlers" (function callbacks registered
for this type of "event"). So, for example,
f I registered my low level app
to be interested in <StartofHeader> and
<EndofHeader> events, I could stop
the parse without going through the rest of the stream.
The implication is that even though XML is
tree-like and has an infix like syntax
(balanced start and stop, like LISP etc),
it remains possible to avoid reading
through the body to get at the
3. These two facts mean we could use
XML to "package up" diverse chunks of
data (using non parsed entities or other
entities if they are XML) or by controlling
packaging within the parser for inlined streams.
What bothers me is that the package as
a whole would have its own DTD/schema
and there is no XML 1.0 mechanism for
viewing the overall schema as resulting
from a composition of schemas. So we
could not "freely" mix and match, because
the composition/decompostion rules
of whole-to-part/part-to-whole are not defined.
AFAIK (as far as I know) anyway.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC