Canonical XML 2.0 Conformance Profiles

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