This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]