- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Tue, 20 Mar 2001 14:22:59 -0800
- To: "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>, "Mark Jones" <jones@research.att.com>
- Cc: <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
>Mark, I am wondering why (1) would have to know "about the
>semantics of a block" to do any sort of dispatching. After
>all, a Web browser does not know anything about the semantics
>of a particular MIME document, and is nevertheless capable of
>firing up the appropriate plugin. Why would block dispatching
>be different?
I agree. If there are things like content encoding or transfer encoding
included (specific to HTTP) then multiple plugins (or "modules") are
fired up in a pipeline. The dispatch mechanism is typically based on the
values of the content-type, the content-encoding, and/or the
transfer-encoding header fields.
The three happen to be related in the following manner
block = transfer-encoding ( content-encoding ( content-type ( data ) )
) )
In our world we can identify the three "functions" with XML NS
identifiers where the content-type identifies the "type" of block be it
a vcard, a privacy statement, an event notification etc.
As Mark describes, at the simplest level, the relationship between
modules can be described in at least three ways
1) Simple ordering of blocks
<TE:transfer xmlns:TE="http://encoding.org/transfer">
...
</TE:transfer>
<CE:content xmlns:TE="http://encoding.org/content">
...
</CE:content>
<V:vcard xmlns:V="http://vcard.org/vcard">
...
</V:vcard>
2) Encapsulation of blocks
<TE:transfer xmlns:TE="http://encoding.org/transfer">
...
<CE:content xmlns:TE="http://encoding.org/content">
...
<V:vcard xmlns:V="http://vcard.org/vcard">
...
</V:vcard>
</CE:content>
</TE:transfer>
3) Referencing of blocks
<TE:transfer xmlns:TE="http://encoding.org/transfer">
...
<encodes href="#b2"/>
</TE:transfer>
<CE:content id="b2" xmlns:TE="http://encoding.org/content">
...
<encodes href="#b3"/>
</CE:content>
<V:vcard id="b3" xmlns:V="http://vcard.org/vcard">
...
</V:vcard>
Which one(s) of these are most suited I think depends on the semantics
of the module. The question is whether these three ways are sufficient
to build more complicated mechanisms that might include logic
constraints etc.
Henrik
Received on Tuesday, 20 March 2001 17:23:37 UTC