RE: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339)

2005-02-05 Thread Scott Hollenbeck

 Having written the datetime support for Apache Axis (a 
 webservice implementation based on XSD schema and having 
 hosted a number of SOAP interop facilities, I am +1 on the 
 regular expression limitation, believe that all dates that 
 that conform to this limitation are valid RFC 3339 and 
 xsd:dateTime values, and believe that it will interop with 
 all of the existing XSD implementations.

I'm not sure that I understand why some folks seem to think that this has to
be an either-or situation.  As Sam noted, it's quite possible to specify
date-time syntax that conform to both RFC 3339 and XML Schema Part 2.
Here's what I did in RFC 3731:

2.4.  Dates and Times

   Date and time attribute values MUST be represented in Universal
   Coordinated Time (UTC) using the Gregorian calendar.  The extended
   date-time form using upper case T and Z characters defined in
   [RFC3339] MUST be used to represent date-time values as XML Schema
   does not support truncated date-time forms or lower case T and Z
   characters.

I then used the xsd:dateTime data type in my schema (with an appropriate
reference to Part 2), and all is well.  The normative text eliminates some
of the 3339 possibilities that don't work or play well with XML Schema.

-Scott-



Re: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339)

2005-02-05 Thread Eric Scheid

On 6/2/05 9:38 AM, Sam Ruby [EMAIL PROTECTED] wrote:

 I am +1 on the regular expression limitation,
 believe that all dates that that conform to this limitation are valid
 RFC 3339 and xsd:dateTime values, and believe that it will interop with
 all of the existing XSD implementations.

where this is the regex? that regex allows this totally bogus value

2005-13-34T25:65:96+00:65

there are test cases in the validator to check this, but those test cases
will no longer be supported by the spec and will thus be a bug in the
validator :-(

e.