This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Schema Exploration...
Jeni Tennison wrote:
> 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.
>
Hmmm, didn't know about all these other cases, wow, thanks.
> 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)
>
The difficulty is that I need to retain relativity in the schema to the
section of the document I am in. If the schema defines a global element
that can be "ref"ed in numerous places in the subtree, then I'll get
back all those ref's and I do not know which one to use.
What I think I'd need to do is: Use your key stuff "key('elements',
$node_name)" to select the nodes with the proper $node_name
and
then Select only the one for this node-set that is a descendant
xs:element of the current xs:element node and does not have any ancestor
xs:elements inbetween itself and the current "working node".
I hope this makes sense?
-Mark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list