Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
