xml-link PIs

> From: Steven J. DeRose <sjd@eps.inso.com>
 
> Ahhh, there's the problem. It is not meaningful to return "replacement text"
> for a span; at elast to a processor that's expecting XML. A span is not an
> XML document; that's the whole point.
... 
> A span is, for most purposes, only meaningful in relation to its context.
> Therefore any model that attempts to define what a span means *apart* from
> its context is doomed to bizarreness and/or failure.
 
Good.  So what http error does this fail with, in the case of an XML browser?
Not found?

At the moment, XML just has link elements.  I don't know if this has already
been suggested, but having link PIs might be very useful too.  When an XML
document is sent by a server, it would allow the particular parts of interest
in the document to be specified for processing at the client. 

For example, take an monthly diary application. The data for the month sent
by the server as an XML document might have in its prolog:

    <?xml-link role="free" behaviour="hilite" show="new"  href="ID(feb11)..ID(Feb21)"?>

The client would highlight the particular days, and grey out the rest of the month.
This is not a format issue, but one of marking data with an initial state for processing
at the client, which is why it belongs in xml-ling not xml-style: we are not specifying
how it is presented, except for the trivial data possible in behaviour.

This would solve the span problem for XML documents: the server can send
some WF document with a link PI, and the client browser (or whatever) can scroll
(or whatever) to the appropriate location.

It also perhaps breaks the strict demarcation between # and ?XML-XPTR=, in that 
it allows the server to do as much is as sensible at its end, and then lets the client
do the rest.  This approach seems more sensible than sending an error always,
requires no new syntax, and moves XML from client/server to peer-to-peer.


Rick Jelliffe

Received on Monday, 16 June 1997 22:17:44 UTC