OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments by Konrad Lanz


Dear all,

After looking at Konrad's comments
It seems to me that he is right in his comments.

The first comment deals with canonicalization management as
it is expressed in the CD. As Konrad mentions, if the
<XMLData> is  canonicalized using the regular Canonicalization
algorithm, it will inherit namespaces defined in any of the ancestors
including the namespace of the dss, bringing undesired ambiguities...
I would say that his suggestion of going for exclusive canonicalization
seems to be correct: in fact, this exclusive canonicalization has been
defined for dealing with data that may be signed and in turn may be
enveloped.

Concerning the second comment, I have been looking the XML Schema 
specification
and it also seems to me that he is correct. I guess that we blindly 
applied verification
by tools that seem not to uncover this kind of mistakes, but the XML Schema
spec seems to say that the presence of xs:any with process lax within a 
choice
with other elements breaks this prinicple of uniqueness.
I guess that we would correct this mistake if we substitute the
elements <xs:any> by <dss:otherXX type="dss:AnyType">....because then 
there is no
need to look into the attributes or the content of the element for 
identifying that
it is the dss:otherXX element and not any of the others present in the 
choice.

Any comment?

Regards

Juan Carlos.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]