Saxon

Legacy ID: #8514699 Legacy Poster: Michael Kay (mhkay)

validates, although the attribute the key is on is optional. A warning to the effect that this effectively renders the optional contraint to a mandatory one would be nice. Thanks for the suggestion. The analysis to do this is quite complex, though Saxon has most of the inferencing machinery in place to attempt it. >the message The child axis will never select any nodes when starting at a node with type of element Sub_2a, as this type requires empty content was semantically not really clear It helps to understand that when a complex type is anonymous, Saxon refers to it in error messages as "type of element E" where E is the containing element. Sometimes this leads to rather awkward sentences. In this case it would probably be clearer to rephrase the message in terms of the element name rather than the type name. I would recommend, however, making more of your types named global types - it comes in useful to have the type names available for use in XSLT/XQuery function and variable declarations.

Legacy ID: #8514872 Legacy Poster: Stefan_E (stefane1)

Hi Michael, thanks very much for the quick answer. Normally, I use global types... indeed then it gets a bit more readable :-) Related to the first: I'm currently playing with this schema (learning...!): [code] <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" targetNamespace="www.bla.com" xmlns="www.bla.com"> <xs:element name="Top"> xs:complexType xs:sequence <xs:element name="Sub_1" type="Sub_1Type" maxOccurs="unbounded" minOccurs="0"> </xs:element> <xs:element name="Sub_2" maxOccurs="unbounded" type="Sub_2Type" minOccurs="0"> </xs:element> </xs:sequence> </xs:complexType> <xs:key name="newKey"> <xs:selector xpath="Sub_1"/> <xs:field xpath="@SubID"/> </xs:key> <xs:keyref name="newKeyref" refer="newKey"> <xs:selector xpath="Sub_2"/> <xs:field xpath="@SubIDPtr"/> </xs:keyref> </xs:element> <xs:complexType name="Sub_1Type"> <xs:attribute name="SubID" use="required"/> </xs:complexType> <xs:complexType name="Sub_2Type"> <xs:attribute name="SubIDPtr" form="unqualified" use="required"/> </xs:complexType> </xs:schema> [/code] Here, the Key/Keyref combination, together with the MinOccurs=0 imply that both Sub_1 and Sub_2 may be missing, but if Sub_2 exists, Sub_1 must be there ...; I find this an easy way to circumvent complex 'Choice' constructs in some cases. Not sure it's clean though ... Stefan

Legacy ID: #8514964 Legacy Poster: Michael Kay (mhkay)

Seems convoluted to me: have you tried playing with XSD 1.1 and xs:assertion?

Legacy ID: #8564413 Legacy Poster: Michael Kay (mhkay)

I've now implemented static type checking for the XPath expressions contained in the selector and field components of identity constraints, so you now get warnings if the field expression is capable of selecting an empty sequence, a sequence containing more than one node, or a node whose type is not simple or complex-with-simple-content. Thanks for the suggestion. There's always a danger with warnings that they may trigger in some innocuous cases, but we'll see how it goes. I've also improved the error messages for axis expressions in the case where the complex type used for the static type analysis is anonymous.

Legacy ID: #8596644 Legacy Poster: Stefan_E (stefane1)

Hi Michael, thanks a lot for your quick implementation! (... and sorry for my late reply; was out on vacation! Stefan