W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2010

RE: RNG schema plans

From: Scott Cantor <cantor.2@osu.edu>
Date: Wed, 20 Jan 2010 21:24:11 -0500
To: "'MURATA Makoto \(FAMILY Given\)'" <eb2m-mrt@asahi-net.or.jp>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
Message-ID: <01e401ca9a40$d1ea5420$75befc60$@2@osu.edu>
MURATA Makoto (FAMILY Given) wrote on 2010-01-20:
> Note that elements of the ds namespace are not allowed, when the
> value of the Algorithm attribute is not one of the four specific ones
> shown in the first definition.

Specific to the example you gave, you do know that exclusive c14n has an
optional child element in a separate schema, the InclusivePrefixes element?

But more to the point, if the wildcard is ##any, the elements *can* be from
the ds namespace. If it's ##other, then they can't. But in a couple of
cases, like with Transform, you have the option between the ##other and the
built-in XPath element, and there's nothing in the spec that says that an
extension Transform algorithm couldn't reuse that XPath element if it wanted

So these things are difficult to nail down because it's intentionally very

> My work would have been easier if I had relied on the latter definition
> only.  But that approach would make validation loose and RELAX NG
> schemas less informative and useful.

It's fine as a goal, I'm just saying that the content models have to be
carefully expressed so as to be consistent with the XSD.

> I would like to be as specific as possible in the first type of
> definitions.  That's why I'm asking.

I think you probably have the built-in ones handled, it's the extensions to
be careful with. There really are no constraints other than what's in the
schema when it comes to those.

It's actually even worse in that a lot of the elements are left as
mixed="true", which was a really unfortunate choice.

-- Scott
Received on Thursday, 21 January 2010 02:24:44 UTC

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