This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
XSLT and XSchema (was Re: keys and idrefs - XSLT2 request?)
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Subject: XSLT and XSchema (was Re: [xsl] keys and idrefs - XSLT2 request?)
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- Date: Tue, 16 Oct 2001 10:15:29 +0200
- Organization: ZKB
- Reply-To: xsl-list at lists dot mulberrytech dot com
David Carlisle <davidc@nag.co.uk> wrote
> 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.
Hmm, this makes me think. While trained as mathematican, i'm
probably working in business software too long:
- define a complex data type "adress"
- use it under various names, which usually denote roles (excuse
the pseudo schema code, can't be bothered to look up the exact
syntax :-)
element address
name: string
zip: string
city: string
...
element order
residentaddress : address
shippingaddress : address
...
Am i mistaken that a valid XML instance would look like
the following?
<order>
<residentaddress>
<name>...</name>
...
</residentaddress>
<shippingaddress>
...
If so, matching the type "address" might be preferable to
writing a template for every address role, or dispatching
via <apply-template select="*[contains(name(),'address']"
mode="address"/>
or something.
I do not claim that the schema above is actually well designed,
if there are alternatives, i'd like to hear about them.
Regards
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list