Re: Remote DOM access ??

At 04:27 PM 10/9/98 +0100, titto@essex.ac.uk wrote:
>
>
>Actually I was not thinking of  it as a way of distributing XML data to a
browser,
>the reason being that in that case you normally have to download the whole
page
>anyway so a cache would make no sense.

Circular problem. If no means of "intelligent chunking" is supported by the
server, you have to download the whole page.
>
>Naturally it would make a lot of sense if the user were navigating on a huge
>quantity of  (possibly dynamically generated) information.
>If so you would definitly want to download only the parts he/she actually
requires
>to see.

Exactly. If you've got a 50 MB aircraft maintenance manual, you can't dump
the whole thing on the client. And typically, it's for these kinds of
documents that SGML markup has been used. Various vertical industries have
large numbers of these documents and are now trying to "XMLify" them. But
as I said in my first message, just adjusting the syntax doesn't solve the
problem. 

>
>> Second, sending less than an entire document raises the problem of
>> supplying context for the "fragment". Context is essential for proper
>> rendering, for example of numbered list items, sections or chapters.
>> Context could be specified using XLink/XPointer syntax; a standard message
>> format for returning this information to the browser along with the
>> fragment itself would need to be specified though.
>>
>
>This is interesting. Could you please provide some details about how it
could work
>?

The current XPointer Working Draft defines a spanning location term:
********************************************************************
3.4 Spanning Location Term

The span keyword locates a sub-resource starting at the beginning of the
data selected by its
first argument and continuing through to the end of the data selected by
its second argument.
Both arguments are interpreted relative to the location source for the
spanning location term
itself; the second argument does not use the first argument as its location
source.

********************************************************************
The context of the "fragment" could be made available to the client by
including the "span" information in the message (header) returned by the
server, with the fragment itself in the message body. 

>
>I would say that the problem of dealing with incomplete XML trees should
be deal
>within the cache itself.
>
>The whole point in having a cache is actually in hiding the fact that we
dont'
>have a complete tree so that the client can still 'see' a plain, complete,
DOM
>tree.

What the client sees is what can be sent and received using HTTP. The
problem is whether the existing HTTP protocol is sufficient, or whether
WebDAV-style extensions are needed. Of course, if they are, then a whole
different venue - an IETF working group - is needed for this discussion. 


Ralph E. Ferris
Fujitsu Software Corporation

Received on Friday, 9 October 1998 13:55:50 UTC