[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: datatype functionality I'd like to see
bry@i... <bry@i...> 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|