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

["Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>]

bry@itnisk.com <bry@itnisk.com> writes:

<snip>Scala discussion</snip>

> 
> > I once had the idea of adding this feature of pattern matching to a
> > (yet
> > another) type system for objects and XML(turning sequences 
> of nodes in
> > something like a record). Glad there seems to be use for it.
> 
> Yeah, after posting I got the idea to implement it as an
> extension to schematron, processor specific, using the 
> skeleton1-5.xsl 
> 
> basically one would have some data types declared at the top
> of the schematron
> schema:
> <sch:dtypes>
> <sch:type name="Date" using="jscript:Date"/>
> <sch:type name="USDate" using="dtype:Date">
> <test>....</test>
> </sch:type>
> </sch:dtypes>
> 
> and then under specific rules:
> <sch:isDtype type="USDate"/>
> 
> obviously I haven't got to the dtype: functionality yet (not
> exactly sure how I want the syntax to work anyway), but 
> checking against anything that inherits from jscript: just 
> means calling a function that returns a boolean dependent on 
> how some typechecking and or loading into a new instance of 
> the object works out.
> 
> Gets me wondering also if Dmitri Novatchev's fxsl might not
> be put to good work to extend schematron with data typing. 
 
When I read your first post two thoughts occurred to me:

1) As has been said many times; one persons metadata is another persons
data. Treating types as anything other than data is wrong, wrong, wrong!
Types are just an attribute that someone can attach to something and
treating anything as though it has a single type only restricts future
extensibility. Any XML schema mechanism that is going to be truly useful
has to allow for elements to behave polymorphically with respect to type
depending on the context in which the element is evaluated.  [I don't
mean to be pedantic here, but this has become a bit of a perma-rant for
me.]  

In your specific case, I think you're going a bit beyond types and also
adding information on how to interpret the data (decoding the state of
issue for the SSN).  However, having a mechanism that attaches such
meta-metadata to type information seems a natural extension to how one
would want to use types: you're defining exactly what one means by
saying that an element has a certain type.

2) Use Schematron.  It seems you've also arrived at that conclusion, but
I'll add another idea; run Schematron under XSLT 2.  Then you can use
regex and all the other XPath 2 features for path traversal in your
Schematron rules.  We're currently doing this to cross validate
documents against each other (things like validate that a diagnosis date
comes after a the date of addmital, etc.) and we're planning on adding
general pattern matching via regex shortly.

Finally, WRT to your thoughts on extending Schematron with data typing;
I think that would be a mistake. From a Schematron point of view -- if
not in general -- I believe typing is just another way of stating
validity rules.  You don't want to hard code your validity rules; you
want the metadata for your applications to drive what type treatment is
relevant in any given context.