W3C home > Mailing lists > Public > public-xmlsec@w3.org > September 2009

Response to enquiries regarding RELAX-NG schema for XML Signature

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>
Message-ID: <016001ca30aa$b326abb0$19740310$@2@osu.edu>

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

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

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:12 UTC