Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] datatype functionality I'd like to see

From: bry@------.---
To: Jeni Tennison <jeni@------------.--->
Date: 7/9/2004 7:39:00 AM
> 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.


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent