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

RE: ACTION-623: Schema update for SerialNumber

From: Pratik Datta <pratik.datta@Oracle.Com>
Date: Tue, 31 Aug 2010 09:22:40 -0700 (PDT)
Message-ID: <12febc39-5895-4377-9f2d-23bb0f4f6099@default>
To: Scott Cantor <cantor.2@osu.edu>, Magnus Nystrom <mnystrom@microsoft.com>, XMLSec WG Public List <public-xmlsec@w3.org>
There is one more datapoint that I would like to add to the discussion.

The main problem is that XML schema says

"NOTE: All .minimally conforming. processors .must. support decimal numbers with a minimum of 18 decimal digits (i.e., with a .totalDigits. of 18). However, .minimally conforming. processors .may. set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number .must. be clearly documented."

However some processors do support more than 18. E.g  JAXB (Java)  maps  "integer" to the java.lang.BigInteger class which has unlimited length.  So my point is that the current schema is not completely broken. If your environment is very controlled and none of the parsers/validators/datatype mappers have this 18 digit limitation, then the schema is fine as is.


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, August 31, 2010 6:40 AM
To: Magnus Nystrom; XMLSec WG Public List
Subject: RE: ACTION-623: Schema update for SerialNumber

> After some investigation, we'd be concerned about doing this change in the
> existing XML Signature 1.0 namespace. While Microsoft implementations
> be able to handle such an update, as noted earlier  by Pratik there are in
> general no guarantees for it and in addition it seems that this was
> precisely the reason namespaces were introduced.

The impact of this is that implementations planning to support general
validation of that namespace with most parsers are forced to modify the
locally installed copy of the schema.

I would ask that an official errata copy therefore be published to ensure

-- Scott
Received on Tuesday, 31 August 2010 16:24:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:14 UTC