- From: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>
- Date: 2 Sep 2010 14:24:24 +0200
- To: "XMLSec WG Public List" <public-xmlsec@w3.org>
I've taken a look at the conformance profiles of canonical XML 2.0 as published on August 31st. By now it seems that this specification---as it is now---implicitly supports three different levels of "REQUIRED/OPTIONAL" for conformance. The first level is shaped by the default values for all parameters: since this is the default, *every* conforming implementation must support this configuration. The second level is shaped by the three "conformance profiles" explicitly listed in section 2.2.1: -ExclusiveMode="true" must be supported for the "1.x features" and "1.x Simple Exclusive" profile (and I'd recommend it as well for streaming), but since its default value is "false", a conforming implementation must support this one in full. -InclusiveNamespace must be supported as well, though default being an empty list -IgnoreComments="false" must be supported for "1.x features" conformance, though default is "true" -XmlAncestors="none" must be supported for "1.x features", though default is "inherit" Hence, these 4 parameters (and all of their combinations) are REQUIRED to implement for conformance with the spec. The third level is shaped by all parameters listed in the spec, but which are not deviating from their default values for any of the given profiles. Hence---as I read it now---these are OPTIONAL to implement. -SortAttributes: though being listed explicitly in all the profiles, its value is always set to "true", hence it is not required to support the "false" case for any of the profiles nor the default. -TrimTextNodes: always set to "false" => OPTIONAL -Serialization: always set to XML => OPTIONAL (btw: the spec says "serializeXML" as default, "Xml" as value in the profiles, and "XML" as enum value in the XML Schema. Should be unified) -PrefixRewrite: always set to "none", rendering "sequential" and "derived" OPTIONAL -QNameAware="": listed explicitly, but for conformance it is only REQUIRED to support the empty version of this parameter (which means doing nothing about this). => OPTIONAL The implicit 4th level is that people might start creating their own parameters and switches here, but I think that's out of scope for the specification. To resume, we require only the conformance to the backward-compatibility profiles. Everything "new" is rendered OPTIONAL, hence will not affect conformance nor interops, right? This should close my Action-625 for now. best regards Meiko -- Dipl.-Inf. Meiko Jensen Chair for Network and Data Security Horst Görtz Institute for IT-Security Ruhr University Bochum, Germany _____________________________ Universitätsstr. 150, Geb. ID 2/411 D-44801 Bochum, Germany Phone: +49 (0) 234 / 32-26796 Telefax: +49 (0) 234 / 32-14347 http:// www.nds.rub.de
Received on Thursday, 2 September 2010 12:24:54 UTC