This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Schema Exploration...
- From: Jeni Tennison <jeni at jenitennison dot com>
- To: Mark Diggory <mdiggory at latte dot harvard dot edu>
- Cc: xsl-list at lists dot mulberrytech dot com
- Date: Fri, 19 Apr 2002 10:23:10 +0100
- Subject: Re: [xsl] Schema Exploration...
- Organization: Jeni Tennison Consulting Ltd
- References: <5.1.0.14.0.20020418172253.01fe0cb0@earthlink.net><3CBF4ABA.40008@latte.harvard.edu>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi Mark,
> This seems the most effective solution and it worked:
>
> <xsl:variable name="my_snode" select="($parent_snode/xs:element |
> $parent_snode/xs:complexType/xs:choice/xs:element |
> $parent_snode/xs:complexType/xs:sequence/xs:element)[@name=$node_name or
> @ref=$node_name]"/>
>
> I don't suspect that a xs:element can fall anywhere else in another
> xs:element. But if it does I can just add it to the select
> statement.
You can have nested declarations -- an xs:element holding an anonymous
xs:complexType that contains xs:elements.
You can also have xs:group definitions at the top level that hold
model groups.
And xs:complexTypes themselves can contain
xs:complexContent/xs:restriction or xs:complexContent/xs:extension
elements, which then hold the content models.
And the content model elements xs:choice/xs:sequence can be nested
inside each other. Plus there's xs:all.
If you're searching for element declarations or references in all
those places, and you're doing it multiple times, all in all it's a
lot easier to create a key:
<xsl:key name="elements" match="xs:element" use="(@name | @ref)" />
Then you can just do:
key('elements', $node_name)
rather than constructing a massive path. It'll be quicker too.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list