Re: optimizing container pages serialization to enable streaming

On 2013-11-11, 11:56 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>This isn't breaking layers between HTTP and payload. Browsers set the
>title of an HTTP frame before parsing it because the head precedes the
>body. Most XML protocols impose some ordering. For a quick survey, see
><http://www.w3.org/2000/03/29-XML-protocol-matrix>.

as you certainly know, XML has an ordered metamodel, which of course makes
it easier to implement incremental parsing and even rendering, if you want
that. and all XML-based protocols i know use XML's built-in ordering,
because it makes a lot of sense to reuse that aspect of the metamodel.

atom *could have* said entry order in the XML does not matter and instead,
each /feed/entry has an @order attribute and then, <entry order="1"> could
be served last, and clients would need to order entries by that attribute.
that of course would be a rather strange XML model (and i've never seen
anybody doing it). with RDF not having an inherent order, that's pretty
much the option you're left with for RDF models that use ordering, with
all the not-so-great side effects. there's little there LDP can actually
do short of (as i think, unduly) constraining RDF.

coming back to alexandre's point: you could imagine a world in which
there's text/turtle, and there's *also* text/ordered-turtle, where some
ordering constraints on the RDF model level filter down into the RDF
serialization (all of them or just turtle?). but if LDP implementors then
have to live with existing serializers in their tool chain, they would end
up *only* supporting text/turtle, unless you would require that LDP must
*only* use text/ordered-turtle.

you could use HTTP conneg for clients to prefer text/ordered-urtle but
still accept text/turtle (because of LDP servers not implementing the new
RDF serialization method). that works, but as any protocol, unless you
make it very clear that both media types MUST be supported, you will most
certainly end up with implementations that implement a subset (because
that was all they were interested in), and then end up being
non-interoperable against implementations implementing a disjoint subset.

as alexandre pointed out: it's doable and it has been done before (in many
protocols out there, based on all kinds of metamodels). it just has
important implications, and is not a choice that should be made without
considering all of them, given the decades of protocol design experience
that's out there.

cheers,

dret.

Received on Monday, 11 November 2013 20:34:32 UTC