[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: datatype functionality I'd like to see

• To: Jeni Tennison <jeni@j...>
• Subject: Re: datatype functionality I'd like to see
• From: bry@i...
• Date: Fri, 9 Jul 2004 09:43:50 +0200
• Cc: xml-dev@l...
• In-reply-to: <1737866067.20040708142016@j...>
• References: <1089278664.40ed12c8dea06@h...> <1737866067.20040708142016@j...>
• User-agent: Internet Messaging Program (IMP) 3.2.2

> This was one of the features of the datatype library language that I
> have been working on [1]. 
hmm, yeah I remember seeing this before but forgot about it.

I think I might have described what I thought about badly, probably from
focusing on the SSN which really had not importance to me other than as an
example.

Let's suppose we have a number of different ways of writing a date, for example
we want a content author just to be able to write <date>January 15, 2003</date>
because for us the most important thing is the ability to data mine information
later, but we would also like to be able to have structures with more specific
date description, like
<USDate><month>12</month><day>03</day><year>1998</year></USDate>
or 
<DanishDate><day>23</day><month>11</month><year>1999</year></DanishDate>

obviously we can go ahead and write validation for each structure, but some
things such as that they are handling an underlying date format should be
maintained. 

Using extensions, which I think this could be done via an exslt extension
actually, then I made something like this:

<sch:dtypes>
<sch:type name="commonDate" using="jscript:Date"/>
</sch:dtypes>

this is bad because it's not cross-processor, then again I can do javascript
extensions in xalan using bsf and I'm sure it's simple enough in the other java
based processors, that's a big part of the market. 

Then my sort of sloppy schematron rules:


<sch:rule context="date">
<sch:assert test="text() | *">date needs to have content</sch:assert>
<sch:assert-datatype type="commonDate" text-seperator="-">a date element needs
to return true against the commonDate datatype</sch:assert-datatype>
   </sch:rule>

   <sch:rule context="USDate">

<sch:assert test="*[1][local-name()='month'] and *[2][local-name()='day'] and
*[3][local-name()='year']">A US Date needs to have a list of
month,day,year</sch:assert>
<sch:assert-datatype type="commonDate" text-seperator="-">a USDate element
needs
to return true against the commonDate datatype</sch:assert-datatype>
   </sch:rule>

<sch:rule context="DanishDate">
<sch:assert test="*[1][local-name()='day'] and *[2][local-name()='month'] and
*[3][local-name()='year']">A Danish Date needs to have a list of
day,month,year</sch:assert>
<sch:assert-datatype type="commonDate" text-seperator="-">a DanishDate element
needs to return true against the commonDate datatype</sch:assert-datatype>
</sch:rule>

so the following 'dates' all validate:

<date>January 03, 1997</date>
<date>01-13-1974</date>
<date><birthday>01-12</birthday><year>2001</year></date>
<USDate><month>12</month><day>03</day><year>1998</year></USDate>
<USDate><month>11</month><day>03</day><year>1998</year></USDate>
<DanishDate><day>23</day><month>11</month><year>1999</year></DanishDate>

but this does not
<date>Heptoary 12, 288</date>

So I suppose other datatype libraries could be built up, a using xsd:date or
something for example. 

• References:
  • datatype functionality I'd like to see
    • From: bry@i...
  • Re: datatype functionality I'd like to see
    • From: Jeni Tennison <jeni@j...>

• Prev by Date: When Semantics Go Wrong
• Next by Date: Encapsulating an XML document within an XML element
• Previous by thread: Re: datatype functionality I'd like to see
• Next by thread: RE: Browser innovation efforts -- where's W3C in this p icture?
• Index(es):
  • Date
  • Thread