In need of some way to set the "isId()" result to true/false as part of the mutable API.

[GoogleCodeExporter]

In porting the latest version (1.5.0) of the Santuario library, I've tripped 
across a change to the implementation that is problematic for our API.

This is manifested by calls to Element.setIdAttributeNode(attr, true), either 
immediately after creating a new attribute, or as an update to an existing 
attribute.

Note that it is theoretically possible to resolve this problem using the 
existing API, because "ContentHandler.attribute()" takes a DtdAttributeKind 
parameter that can set this to DtdAttributeKind.ID. Which means, as a 
work-around, it is theoretically possible with the current API to solve this 
problem. For an existing Attribute, one can test with NodeInformer.isId() - if 
it isn't, one could delete the attribute, create an equivalent one, and re-add 
to the document.

In practice, there are two problems with the work-around:
a) it is woefully inefficient to set a boolean flag by deleting and recreating 
an attribute.
b) in actual usage with the Santuario library, the "ProcessingContext" is only 
used for test cases, not for the processor implementation, which means there 
isn't any way to actually get a FragmentBuilder.
c) This leaves the NodeFactory.createAttribute() method inconsistent with the 
ContentHandler interface.

Proposed solution:
a) Update NodeFactory.createAttribute() to take a DtdAttributeKind parameter
b) Add method to MutableModel.setIsId() which will set this.

Note that DOM level 3 adds three methods to the Element definition (and exposes 
this problem):
setIdAttribute
setIdAttributeNS
setIdAttributeNode

Original issue reported on code.google.com by eric%tib...@gtempaccount.com on 16 Apr 2012 at 3:29

[GoogleCodeExporter]

Is this a real concern?  The only reference to setIdAttribute I saw is in 
DOMCryptoContext.  Can it be that this is only in programmatic tests and we can 
rewrite them?

Original comment by anli.shu...@gmail.com on 14 May 2012 at 3:08

[GoogleCodeExporter]

And even DOM's setId has the option of throwing 
DOMException - NO_MODIFICATION_ALLOWED_ERR: Raised if this node is readonly. 

http://docs.oracle.com/javase/6/docs/api/org/w3c/dom/Element.html#setIdAttribute
(java.lang.String,%20boolean)

Original comment by anli.shu...@gmail.com on 14 May 2012 at 3:17

[GoogleCodeExporter]

Yes, definitely a real concern. The "mutability" question is already a given - 
if you're signing/encrypting, then the document already has to be mutable, so 
it would not be consistent to reject this request.

I implemented the changes in GenXDM, and then applied the changes in Santuario, 
and I found at least fifteen hits on the method that I had to add. Which code 
base did you search through?

I've filed 
http://code.google.com/a/apache-extras.org/p/santuario-genxdm/issues/detail?id=1
8 to see if it is possible to update the Santuario project to eliminate the 
need to apply this mutation, but that's potentially a big change.

Original comment by eric%tib...@gtempaccount.com on 14 May 2012 at 3:41

[GoogleCodeExporter]

Wrong search...  It seems that the settings are legitimate though: they're on 
new signature elements being created in previous steps... As for efficiency 
we're handling only one or two ids per signature...   

Original comment by anli.shu...@gmail.com on 14 May 2012 at 8:03

[GoogleCodeExporter]

Fixed at r327

Original comment by eric%tib...@gtempaccount.com on 16 May 2012 at 12:36

• Changed state: Fixed