OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [security-services] the Time Issue

I'm sorry, you're right, I wasn't clear enough.  I meant that the issue 
has been discussed in XML Schema mailing lists and the soapbuilders 
mailing list.

The issue is, basically, this.  XML is a "printed" representation, so if 
you send schema-typed data, you have all the standard round-off and 
truncation kinds of issues for floating-point numbers.  For example, 
what happens when your SOAP layer converts the XML text node 
"2.99999999999999999" into a local floating-point number?  The XML 
Schema spec makes no requirements.  And the problem is compounded when 
you convert the local floating-point number back out to an XML text node 
for output.

That concept, XML->native->XML, also known as the conversion from Schema 
lexical space to value space and back, is known as round-tripping.  And 
if you search the archives (e.g., [1]), you'll see it's an issue.

I strongly suggest that SAML avoid arbitrary precision issues and 
mandate millisec or microsec granularity, only.

> I can see no scenario in SAML where this is required or even desirable. 
> I suggest we adopt as an explicit non-goal the ability to convert the 
> contents of an assertion to a local format and back. If you need the 
> orginal for some purpose such as audit, just keep a copy. Does the time 
> precision issue still exist if this non-goal is accepted?

Yes, see above.


[1] http://groups.yahoo.com/group/soapbuilders/message/1793

Zolera Systems, http://www.zolera.com
Information Integrity, XML Security

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC