RE: Date type and patterns

Hi Danny,

> Based upon our current specifciation we have a defintion of a date
type
> defined to only have the year value required, month and day are
optional
> and there should be no time information (we have a datetime type
defined
> for this).

If you declare it as "date", you must have a month and day.  This is the
lexical representation described in the spec.  If you want the month and
day to be optional you could define it this way:

<xsd:simpleType name="dateWithOptionalParts">
  <xsd:union memberTypes="xsd:date xsd:gYear xsd:gYearMonth"/>
</xsd:simpleType>

This would allow it to be either a full date, or just a year (gYear), or
a year and month (gYearMonth.)


> It looks like a date type is required to be a year month day and it
has
> optional time portion that if used would make it look like a datetime
> type.

There is an optional time _zone_, but the time cannot be included in
values of the "date" type - you would use "dateTime" for that.

> 
> After reading the Scheam spec it looks like the definition of the date
> type
> requires a year month and day and it allows this to be changed via a
> pattern like this:
> 
>          <xsd:pattern value="\d{4}(\-\d{2}(\-\d{2})?)?"/>
> 

You can restrict the value of a "date" further using a pattern (e.g. if
you wanted it the year to always be "2002"), but the value still has to
be valid according to the date type.  You can't use a pattern to extend
the set of values allowed by a type.

> MSV doesn't seem to see the pattern when associated with a date type,
but
> if I change it to a string type it validates without a problem.

MSV is correct.

> 
> XSV reports succes in validation but it also didn't recognize the
problem
> before when the type was just date, so I'm not sure anything has been
> helped with this change.

I think XSV reports no problems because it does not validate simple type
values yet.  See the XSV site for information on what is not currently
supported.
> 
> When can we expect to have a refernece parser that is complete and
> accurate
> to the current version of the specs? I see we are already looking for
> input
> for 1.1 when we still don't have a complete implementation of v1!
> 
> Who has the best and most complete parser at this point in time?

I recommend Xerces 2.0.1.

Hope that helps!

Priscilla

-----------------------------------------------------
Priscilla Walmsley             priscilla@walmsley.com
Author, Definitive XML Schema     (Prentice Hall PTR)
-----------------------------------------------------
> 
> ..dan
> 
> It seems that MSV
> ---------------------------------------------------------------------
> Danny Vint
> ACORD                                       1 Blue Hill Plaza
>                                             PO Box 1529
> dvint@acord.org                             Pearl River, NY 10965
> http://www.acord.org
> 
> Voice:510:522-4703
> FAX: 801-749-3229
>

Received on Monday, 22 April 2002 08:23:46 UTC