[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Multimedia package patterns possibly relevant to packaging issues
Dale 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' cid='MessageRoutingInfo' Purpose='MessageRoutingInfo' > An XML/IDREF approach <DocumentReference Id='AB273' DocumentType='Text/XML' idref='AC56872' 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' URI='urn:example.com:ACV-CN-1999/2456#MessageRoutingInfo' 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. Thoughts? David -----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 issues <daleActionItems> <references> A good initial overview is found at http://www.xml.com/pub/98/07/binary/binary.html In particular, compare listing3 (all xml with some external referencing) to listing4 (multipart/related using cid URNs). (SMIL examples) Then look at http://www.w3.org/TR/WD-xml-fragment To speed things up, jump to Appendix C.2, "Use of external entities and MIME packaging" </refences> <optional> 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 external. (http://www.xml.com/pub/98/08/xmlqna2.html) 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 headers. 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. </optional> </daleActionItems>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC