W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2005

Re: DOM Interfaces & XInclude

From: Ray Whitmer <ray@xmission.com>
Date: Sat, 16 Apr 2005 16:37:22 -0600 (MDT)
To: Frans Englich <frans.englich@telia.com>
cc: www-dom@w3.org
Message-ID: <Pine.LNX.4.62.0504161601060.26616@xmission.xmission.com>

On Sat, 16 Apr 2005, Frans Englich wrote:

> I don't know if a DOM interface for XInclude is a good idea, but it would be
> interesting to hear people's thoughts on the matter.

I think all you are asking for is an option for XInclude, not really any new
interface as I would interpret the word.  I am not familiar enough with 
XInclude to know for sure, but it would seem to be comparable to the option 
in DOM whether or not to expand entities.

The difficulty in DOM with handling entities is that it wants to make the
view of the document available with entities expanded (the expanded part
read-only) while permitting an application to save the document with the
original entity references after other parts have been modified.  It is 
frequently the ability to mutate the document hierarchy that has complicated
DOM beyond being a simple interface to the infoset.

There is one other significant complication to entities that is unlikely to
arise with XInclude related to the fact that the same entity if it appears in
different document locations can produce different infoset fragments because
it may be subject to different namespace definitions for the same prefix in
different locations.  With XInclude all such resolutions happen before the
transform in the original respective documents, so this should not occur,
although the tree will look a bit funny because where the XInclude occurred
there will be a shift in effective namespace definitions, possibly without
even actual definitions, but save can take care of this by generating them.

A simplest alternative would be completely invisible, giving the program no
control or ability to detect where the XInclude occurred.

I do not know how important it would be for an editor to get the added info
that is available in the case of editors, but if such were not made available,
it wouldn't seem to hard for editors to make do, since XInclude, unlike
entities, uses elements that any editor can detect and use.

If this can be truly implemented as only a load option, you should experiment
with an implementation in one of the open source implementations such as
Xerces and see if you can add it or get someone else to add it.

But I question what happens at save time:

1.  The XInclude has become an indistinguishable part of the document.
2.  The DOM implementation is expected to be smart enough to save the document
back out with only the original XInclude elements, not the expansion.

If the answer is (2), as it is for entities, then what happens if the program
has mutated the stuff.  Is it supposed to be read-only, like the content under
expanded entity references?  Then how does the application know not to 
mutate what was there?

DOM is fairly easy to expand.  I suspect your strongest case for a new
standard option would be made by implementing it and demonstrating the concept
in concert with others who see it as a benefit.  I never went very far with
XInclude, because it never seemed to solve (when I last saw it) character
entities, parameter entities, and other aspects of entities I found most-
useful but those advocating XInclude wanted to avoid, sure that XInclude would
be of compelling use without it.

Even with or without W3C blessing, this would seem to be a useful approach
for the community of likely XInclude users.

Any other takers on this list?

Ray Whitmer
Received on Saturday, 16 April 2005 22:37:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT