<extended>
<simple .../>
<simple .../>
</extended>
<!-- simple being used instead of locator -->
...
<extended>
<locator .../>
<locator .../>
<simple .../>
</extended>
<!-- simple being used as well as locator -->
...
<extended>
<locator .../>
</extended>
<!-- only one locator -->
...
<extended>
<extended>
<locator .../>
<locator .../>
</extended>
<extended>
<locator .../>
<locator .../>
</extended>
</extended>
<!-- hierarchical extended -->
...
<foo>
<locator .../>
<locator .../>
</foo>
<!-- foo is the root element and has no xlink:form attribute -->
...
The problem is that all of these throw no error in the parser as they are
probably impossible to constrain except in very spartan DTDs. I suspect
most are not productive, but some might be valuable on occasions I have or
haven't thought of.
This is an important occasion that there is a clear requirement for
applications to apply semantics to parts of one of the specs. We already
have to write an attribute processor and I'm interested in knowing how much
additional processing any conforming Xlink software is going to have to do.
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg