Schema Validity and Syntax Constraints (Was: Followup on I18N Last Call comments and disposition )

[Thread moves back to question of whether a valid XML Signature is
well-formed, well-formed+constrained, DTD Valid, or Schema Valid]

At 05:43 PM 7/18/2000 -0400, Donald E. Eastlake 3rd wrote:
 >>Does the text [1], "Thus, to interoperate between different XML
 >>implementations, the following syntax constraints MUST be observed" mean
 >>ONLY when a DTD/schema is not present, or any XML content being signed can
 >>never have attribute values? (I assume not).
 >>[1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-XML-1
 >
 >I meant something like "Signatures which do not follow the three
 >syntax constrains below will generally fail to interoperate if any XML
 >implementation that ever tries to verify them does not have the
 >required DTD/schmea(s) present." 

Ok... (So this isn't required for conformance, just warning?)

 > Note that it is not just the dsig
 >DTD/schema but for anything within the SignedInfo and other stuff in
 >the same document referenced by any References.  In generaly, it seems
 >like mandating these syntax contraints would be a good idea.
 
I expect you don't mean "Signatures which do not ..." because I'd expect a
Signature application would have some sense of the  Signature DTD/schema;
you mean content being signed? This also returns us to the question as to
whether we expect Signature verifying applications to check for XML DTD or
schema validity.

DTD is out for enveloped/envloping signatures.

I argue a conformant Signature application needs to valdiate the Signature
element against the Signature schema. Fortunately, we aren't using that many
features, we could get away with some text akin to (tweaked Connolly

    a conforming digital signature element is an element [information 
    item] that is _schema-valid_ with respect to the schema element 
    declarations found within each element's respective description and
    definition.

 >>And with respect to the text, "2. all entity references (except "amp",
"lt",
 >>"gt", "apos", "quot", and other character entities not representable in
the
 >>encoding chosen) be expanded" How would you respond to Martin's comment? I
 >>think the point was to say these things don't vary as they are defined by
 >>the doctype and convention, so that's why we don't mind if people use them
 >>in their non-expanded form: & = &
 >
 >You have to be able to use most of the enumerated entities to properly
 >express things without tripping up the XML parsing and they are
 >pre-defined by the XML 1.0 specificaztion.  & = &
 >"Expansion" is an odd term in this case as they change into one
 >character so they get shorter.
 
I tried to rewrite the text of this section and the one below but was unable
to do so? Could you take a stab such that Martin's comments are addressed? 

 >>[1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/#sec-XML-1
 >>
 >>At 15:44 6/27/00 -0400, Joseph M. Reagle Jr. wrote:
 >> > >7.1, second list, point 2: 'except... and other character entities
 >> > >not representable...': This may be wrongly understood to mean that
 >> > >e.g. é in a HTML document shouldn't be expanded if
 >> > >the encoding is US-ASCII. This is of course wrong, é
 >> > >should in this case be changed to the appropriate numeric
 >> > >character reference (and the spec may have to say whether
 >> > >these should be decimal or hex,...).
 >
 >I guess that's right, ie, characters not representable should be
 >changed into a numeric character reference.  But I can't see how it
 >matters whether it is decimal or hex.  Any conformant XML 1.0 reader
 >will translate the numeric character references into the appropriate
 >character.  Things which depend on the surface input character string
 >and assume no XML processing are completely screwed as far as
 >interoperability anyway.


_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Friday, 21 July 2000 15:05:14 UTC