RE: [xsl] keys and idrefs - XSLT2 request?

["Hunsberger, Peter" <Peter dot Hunsberger at stjude dot org>]

> Knowing an attribute is a date is good, I'd hope to use date arithmetic
> in XPath 2, but I can't imagine ever wanting to (for example) match
> elements by some complex schema type rather than name. I want the
> complex types to validate the document, but once I know the document is
> valid I just want to match on element names (don't I?) Perhaps I don't
> and there are real use cases, and I just need to be educated....

David,

Matching by object type seems to be useful capability to me, although I'm
not sure I want it implemented  in deference to getting anything else
done...  

In our case, we have an XML document that is really more of an mapping of an
object space that needs to be invoked in the proper hierarchical order.  The
XSLt happens to, in turn, map those objects to HTML.  In general, as an XSLt
user I'm more interested in saying, run this object, spit out the results,
now run this object and spit out the results.  Now one could argue that the
name identifies the object, but date is a good example.  Since the XML is
expose to the end users (template designers in this case) I don't want to
have get into some complex hierarchy of date naming (date of birth,
admission date, start of trial date, we've got 100's of them).  I'd rather
just have the template writers use something like:

	<dateofbirth/>

etc.  

I could have:

	<date type="birth"/>

but in all other cases (so far) the object name maps directly to the
underlying object space, so the template designer has to know this is an
exception.  The alternative:

	<dateofbirth type="date"/>

is easier to map to the objects, but I can just hear the complaints about
the redundancy of this implementation.

To give some more context, in our case, all HTML date input fields are
accompanied by a date selection applet invoked from a specific image button
with some attached Javascript onClick handler -- I don't want this code in
more than one place.  So, although all date types can theoretically be
handled generically, if I'm not very careful, my template ends up looking
like:

	match="date-of-birth | admission-date | ....">

for 100's of date types. Substring match against the string "date" becomes
the required implementation, but this may in turn lead to some non-intuitive
template behaviors, with maintenance issues of having to go back to recode
the "date" handling template when some other object with the string "date"
in it, that isn't a date, turns up.

For us, just being able to code a simple "typed" match without jumping
through any syntactical hoops would certainly make the XSL easier to
understand and write.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list