- 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
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 UTC