- From: Scott Cantor <cantor.2@osu.edu>
- Date: Tue, 8 Sep 2009 13:35:04 -0400
- To: <eb2m-mrt@asahi-net.or.jp>
- Cc: "'XMLSec WG Public List'" <public-xmlsec@w3.org>
Hello, I was charged with evaluating the comments you submitted regarding the RELAX schema for the current and future XML Signature specs. I've collected up what I was given by the WG chair here. An initial comment: The schema currently posted on the W3C site is apparently invalid (according to the limited checking I've done). There's never been a "normative" RELAX schema for any version of the specification, XSD has been the normative one. I don't think there's any objection to publishing a non-normative RELAX schema, but obviously the point of such a schema would be to validate any (and only) documents that would be considered valid by the XSD. With respect to the draft schemas you submitted, I believe you were proposing altering things that the XSD does today, and that wouldn't be acceptable. On to your comments: > First, I don't understand why you specify a DTD. A DTD was provided with the original spec because there was apparently demand from somebody involved in the TC for doing so. As of 1.1 PWD, it's been removed as there is no support for maintaining it as we go forward. > Second, do you really allow any namespace by ##any? > Isn't ##other more appropriate? Now, you can embed <Signature> > as a child of <CanonicalizationMethod>. Is this intentional? All of your comments related to why certain things were done are largely moot, because the schema can't be changed at this stage. I happen to agree with some of them, but they're not fixable, unfortunately. With respect to this question, the wildcards that use ##any are in some cases there because there was no interest in constraining what particular extension content could appear given no knowledge of the algorithm definitions that would be making use of the extensions. Plenty of content from any namespace could be very strange to find inside that or other elements, not just a Signature. > First, version="0.1" in the schema element is confusing. Since the > spec is "1.0", it should be "1.0". I agree. It's possible we could change that given that the version of a schema has no normative intent, but I think in general we're just stuck with it. > Second, do you really need mixed="true"? There is nothing syntactically > incorrect, but the use of mixed contents in non-narative documents > looks strange to me. Totally agree, and also not fixable. I may actually push for the 1.1 spec to just outlaw using mixed content, and I almost certainly will do that for 2.0. But the schema can't be fixed. Thanks for your interest, -- Scott
Received on Tuesday, 8 September 2009 17:35:41 UTC