Re: Remote DOM access ??

At 05:07 PM 10/7/98 +0100, titto@essex.ac.uk wrote:
>Mike Champion wrote:
>
>> There is a group of us who very much want to define a standard here for
>> what might be called a "Repository Object Model" based on the DOM.  It is
>> not on the priority list for Level 2.
>>
>
>Could you tell me a little more about that ?
>
>
>> Seems reasonable to me.  If your architecture allows some server-side
>> processing to keep the full parsed document on the server and intelligently
>> query and selectively pull pieces down to the client, that might work
better.
>>
>
>Are you aware of any existing implementation of an XML cache ?
>
>I can't believe that I'm the only one to have stumbled on this problem.

The problem has been on some people's minds for quite a while... One reason
it hasn't received more attention is the previous history of SGML file
*distribution*. In the pre-Web days, SGML files were generally distributed
on CD-ROM along with the browser. When the Web came along, absent a
widely-available Web browser that could read SGML, publishers took to
"down-translating" SGML files to HTML. The main attempt to introduce an
SGML Web browser, SoftQuad (now Interleaf's) Panorama, met with only
limited success. So the problems associated with serving SGML over the Web
haven't received the attention that's required.

The XML effort was in fact organized by Jon Bosak, who has a lot of
experience with Web publishing, "to enable generic SGML to be
served, received, and processed on the Web in the way that is now possible
with HTML." The XML effort focused, though, on simplifying SGML syntax in
order to promote tool creation. The problem that you're raising has been
outside the scope of the XML effort.

There are several issues involved in addressing it though. First, note the
implication in the phrase (from the abstract to the specification) "in the
way that is now possible with HTML." That's another way of saying users
should be able to access XML documents through Web browsers using HTTP. Any
general solution has to start from there. 

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.

Of course, the problems associated with returning XML document "fragments"
apply not only to caching, but to querying and to XLink/XPointer operations
as well. Fujitsu Laboratories has just demonstrated (at the GCA conference
in Tokyo last week) the latest version of its "HyBrick" browser, integrated
with an XLink/XPointer engine. The XLink/XPointer operations are currently
available only on local files. Addressing the issues of XML "fragment"
retrieval is a critical next step to making XML content available on the Web.


Ralph E. Ferris
Fujitsu Software Corporation

Received on Thursday, 8 October 1998 17:58:27 UTC