|
Subject: Re: [xsl] Schema Exploration... From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Fri, 19 Apr 2002 10:23:10 +0100 |
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
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: [xsl] Schema Exploration..., Mark Diggory | Thread | Re: [xsl] Schema Exploration..., Mark Diggory |
| RE: [xsl] Replacing images with alt, Michael Kay | Date | RE: [xsl] Invalid Character, Michael Kay |
| Month |