- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Wed, 04 Apr 2001 14:21:46 +0200
- To: Mark Jones <jones@research.att.com>
- CC: hugo@w3.org, xml-dist-app@w3.org
Mark, Catching up on this one... R802 may indeed lead to some representation that physically partitions the message, and header/body is one such representation; but then it only helps the final receiver "process XMLP blocks intended for them without processing the entire message", *not* the intermediaries. And I agree with you, "what if header blocks reference body blocks"? A solution that comes to mind is to order blocks, so that blocks targeted at the same... thing... (waiting for a conscencus here) are contiguous. But then the order for one intermediary may not be optimal for another intermediary. (And besides, I think there is a conscencus that the ordering of blocks is semantically important, and so it may not be changed lightly!) Jean-Jacques. Mark Jones wrote: > Hugo Hass wrote: > The whole point about this body/header difference was that carrying > out the "body" semantics did not require a different element and that > it could be done with a single element and attributes. > > I still believe that, as Jean-Jacques suggested, it makes more sense > to use only one element. > > I like the elegance of a single construct (block), perhaps nested > inside a grouping elements (Blocks??). Henrik points out that there > is a requirement, however, R802, that may lead to some representation > that physically partitions the message: > > R802 -- XMLP must also enable processing intermediaries to locate > and process XMLP blocks intended for them without processing the > entire message. > > I'm not sure what representations might satisfy this. Also, I am not > sure how this requirement squares with the possibility of forward > references using the id/href mechanism. What if header blocks > reference body blocks?
Received on Wednesday, 4 April 2001 08:22:51 UTC