> What about a middle ground for transition. An explicit call has to be
> made into the library to enable the fudged Id in the signing case?
Yes, I could see making it optional behavior.
-- Scott
What about a middle ground for transition. An explicit call has to be
made into the library to enable the fudged Id in the signing case?
Cheers,
Berin
Scott Cantor wrote:
I agree with that. I don't think the library should be guessing what an
ID is in the signing case.
+1. With DOM3,
> I agree with that. I don't think the library should be guessing what an
> ID is in the signing case.
+1. With DOM3, the reasons for this hack are gone.
-- Scott
Berin Lautenbach wrote:
Milan,
Anything can be an Id, but it needs to be defined as such within the
DTD/Schema (type=ID). In the XML DSIG spec, anything that has an
type="ID" attribute is called "Id", so references, objects, manifests
etc should all have attributes called Id.
But if the file
Milan,
Anything can be an Id, but it needs to be defined as such within the
DTD/Schema (type=ID). In the XML DSIG spec, anything that has an
type="ID" attribute is called "Id", so references, objects, manifests
etc should all have attributes called Id.
But if the file is parsed in non-validat
Apache Java libraries allow URI "Id" attribute to be "Id" or "id".
Apache C++ libraries allow only "Id". W3C recomends "Id". What is right?
[snip example..]
Was this bug fixed?
I am not entirely clear what you think is a bug?
If the W3C RECOMENDS "Id" (and I haven't read the spec lately, so I
Title: [java & c++] URI
Apache Java libraries allow URI "Id" attribute to be "Id" or "id". Apache C++ libraries allow only "Id". W3C recomends "Id". What is right?
XML Signature Example:
http://www.w3.org/2000/09/xmldsig#"&
