This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4170 - [UPD] W3C DOM cannot rename a PI
Summary: [UPD] W3C DOM cannot rename a PI
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-09 18:29 UTC by John Snelson
Modified: 2007-01-30 13:03 UTC (History)
1 user (show)

See Also:


Attachments

Description John Snelson 2007-01-09 18:29:28 UTC
XQuery Update specifies an update primitive that changes the name of a processing instruction without changing it's identity. However, implementation like the one that I've been working that have a data model based on W3C DOM cannot do this, since W3C DOM does not provide a way to rename a processing instruction.

Can I suggest that you either allow the processing instruction's identity to change in this case (and deal with all the possible variable value fix-ups), or don't allow processing instructions to be renamed at all.
Comment 1 Michael Kay 2007-01-09 20:34:37 UTC
Surely there are so many differences between the DOM model and XDM that (a) any implementation based on DOM is going to have do do some heavy mapping, and (b) it's unrealistic for anything in DOM to influence the language design?
Comment 2 John Snelson 2007-01-10 10:26:29 UTC
Not at all. XQilla's mapping from the Xerces-C DOM to the XDM is fairly lightweight, and generally a good match. I suspect XQilla is not the only XQuery implementation to be built on top of a W3C DOM, so this issue needs to be addressed.

W3C DOM is one of the only other specifications that has done some thinking on the issue of updating an XML data model, so I think it would be wise to at least consider their motivations, even if you find you do not agree with them.
Comment 3 Michael Kay 2007-01-10 10:47:21 UTC
The issue needs to be addressed by implementors, but I don't think it needs to be addressed by the XQuery WG. There were good reasons why the WG chose to specify XQuery in terms of the XDM, and mapping other models to XDM is someone else's problem. Such mappings will rarely be perfect. People attempting to map SQL-based models to XDM have an even bigger problem.
Comment 4 John Snelson 2007-01-10 11:21:12 UTC
At the very least, the spec needs to make it possible for implementers to solve this problem. There is no way to change the name of a processing instruction in W3C DOM without changing it's identity. Is it the intention of the XQuery working group to doom all implementations based on W3C DOM to being non-conformant?
Comment 5 Michael Kay 2007-01-10 12:47:46 UTC
I'm not speaking for the WG.

But I would think that when you're doing two-way mappings rather than one-way, a lot of systems are going to have problems if they use an underlying model that doesn't map accurately to XDM. I don't know how you're doing your mapping, however. In Saxon, when it runs over a DOM, there is already an indirection between Saxon node identity and DOM node identity, for example one Saxon (XDM) text node can map to several DOM text nodes. Frankly, there are so many glitches you have to work around in mapping DOM to XDM that I'm surprised one more should cause you any particular difficulties.

I would certainly rather see products saying "This feature doesn't work in this environment because DOM can't do it" than to see the XQuery spec saying "This feature doesn't exist in the language because implementors can't see how to make it work when the implementation platform is a DOM". In fact, I have a general view that arguments to restrict the language or reduce its orthogonality because of perceived implementation difficulties are nearly always wrong. (Certainly, when I've advanced such arguments myself I've usually regretted it later.)
Comment 6 Martin Probst 2007-01-11 08:13:50 UTC
> Can I suggest that you either allow the processing instruction's identity to
> change in this case (and deal with all the possible variable value fix-ups), or
> don't allow processing instructions to be renamed at all.

If your implementation fixes all the variables and other corner cases, it should be unobservable to the user if the node identity change, shouldn't it? In that case you're certainly conformant to the spec - in my understanding it doesn't require your internal node id to be equal, but rather 'node is node2' to be true, so if you can ensure that it's no problem.
Comment 7 Jonathan Robie 2007-01-29 22:35:11 UTC
The XML Query Working Group has decided to make no change with respect to renaming processing instructions, because we like the way that XQuery works here. 

We recognize that this will force some implementors who are implementing on top of the DOM to document a divergence from the specification, perhaps stating that the operation could not be supported because of limitations in the DOM.