- 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>
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 to. So these things are difficult to nail down because it's intentionally very open. > 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