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

Re: Canonical XML 2.0 Conformance Profiles

From: <Frederick.Hirsch@nokia.com>
Date: Fri, 3 Sep 2010 00:47:58 +0200
To: <Meiko.Jensen@ruhr-uni-bochum.de>
CC: <Frederick.Hirsch@nokia.com>, <public-xmlsec@w3.org>
Message-ID: <7623D61B-8A0C-4BB0-BF78-BAD58A7629E0@nokia.com>
To repeat what I think you said, Does this mean there are really two conformance levels?

1. Support C14N2 with defaults as listed for all parameters. All other parameters not at default settings are optional.

2. Also support ExclusiveMode, InclusiveNamespace, IgnoreComments and XmlAncestors parameters with values other then defaults.



regards, Frederick

Frederick Hirsch
Nokia



On Sep 2, 2010, at 8:24 AM, ext Meiko Jensen wrote:

> 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 22:48:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 2 September 2010 22:48:41 GMT