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: 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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC