Subject: RE: [xsl] keys and idrefs - XSLT2 request? From: "Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx> Date: Mon, 15 Oct 2001 12:14:14 -0500 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] keys and idrefs - XSLT2 r, Mulberry Technologie | Thread | [xsl] schema-1 (was something about, David Carlisle |
ANN: typeTagger v 0.1 (was: Re: Sch, Francis Norton | Date | Re: Schemas in XSLT 2.0 (Was: Re: [, Jeni Tennison |
Month |