This e-mail summarizes ACTION-649, ACTION-650, ACTION-651 relating to possible next steps with X509SerialNumber.
To remind ourselves, the issue here is that this element is defined as an integer which inherits an 18 digit limit from the XML Schema decimal data type. That's not long enough for our purposes.
1. Errata and process
We had various conversations about "publishing an erratum" against this document or some such. The W3C errata process is summarized here:
http://www.w3.org/2005/10/Process-20051014/tr.html#errata
Fundamentally, WGs document "proposed" errata on a spec's errata page. Those errata become normative when they're incorporated into a new version of the specification. There's no such thing as a normative erratum that the group doesn't intend to ever include into a spec.
Another basic point: We're having the occasional conversations about "the 1.0 namespace". That doesn't help clarifying the conversation.
What we're dealing with is the namespace "http://www.w3.org/2000/09/xmldsig#". The normative spec for this namespace is currently XML Signature 1.0 Second Edition. XML Signature 1.1. is intended to supersede that specification and, when it becomes a Recommendation, will be the specification that's normative for this namespace. The normative schema for this namespace is the one that is linked from the currently normative recommendation. The fact that we make a schema document available at the namespace URI is a convenience; it does *not* confer normative status.
For the purposes of this conversation, I'd like us to first think about what the normative situation for this namespace should be, i.e., what's the right thing to say about X509SerialNumber. We can then think about where we make changes (if any), and further talk about what we want to do to the schema documents that are floating around.
2. XML Schema
From discussions, it looks like there's pretty much no chance to get Schema fixed up. However, we're certainly free to define a new data type that has appropriate properties. It would presumably be a facet of xsd:string, with a regular expression that limits the lexical space.
3. Thinking things through, I believe that we have two coherent proposals on the table, with a few wrinkles around what the second means for the namespace URI:
(a) Do nothing.
(b) The normative situation should be that X509SerialNumber is a facet of xsd:string, with appropriate constraints on the lexical space. Those constraints should be in line with the constraints we're imposing now (i.e., it's the lexical representation of an xsd:integer). The schema documents published with old recommendations (obviously) do not change, but schema documents shipped with Signature 1.1 (and then 2.0) will change. Since the normative schema is the one linked from the currently-relevant Recommendation, the only remaining question is what we do with the namespace URI.
There are several perfectly legitimate things a namespace URI could point at:
(i) the currently normative Recommendation
(ii) the schema document from the currently normative Recommendation
(iii) an HTML page that describes the current use of this namespace and points at various schema documents and various specifications
Hope this helps,
--
Thomas Roessler, W3C <tlr@w3.org> (@roessler)