Let’s just clear the air up front: I like XML Schema. It’s convient. It’s solves about 90% of all XML validation concerns. It’s concise.
xsd) attributes. It appears that if you have extended XSD in any way then there’s no way to access this information. Why allow it to be specified if one cannot access it?
I have been banging my head looking for a way to access non-native attributes of an XSD via PSVI. The problem I kept hitting was that the XSD API defines a seemingly limited
XSAnnotation. There is only a
annotationString method for retrieving the annotation. Taken literally (which is what I was doing) this will return the information within the
<xsd:annotation> and that’s it.
I started looking for alternative techniques. I found some interesting information regarding
SchemaAnnotation and non-native attributes. And this got me to thinking. I started to do some code splunking in Xerces and found that the member that backs
getAnnotationString() looks like:
// the content of the annotation node, including all children, along // with any non-schema attributes from its parent private String fData = null;
Well that certainly does not match the PSVI description of “A text representation of the annotation”. The key is the “along with any non-schema attributes from its parent”. If your XSD looks like:
<xsd:element name="something" myNS:name="Something"> <xsd:annotation> <xsd:appinfo>Stuff</xsd:appinfo> <xsd:annotation> ... </xsd:element>
getAnnotationString() will return:
<xsd:annotation myNS:name="Something" ... > <xsd:appinfo>Stuff</xsd:appinfo> <xsd:annotation>
Now those of you that are careful readers are likely sitting there wondering how this is even possible since it’s inconsistent. You’re wondering what happens when your XSD looks like:
<xsd:element name="something" myNS:name="Something"> <xsd:annotation myNS:name="Something else"> <xsd:appinfo>Stuff</xsd:appinfo> <xsd:annotation> ... </xsd:element>
Well, I’m sure you’ve already guessed the answer:
<xsd:annotation myNS:name="Something else" ... > <xsd:appinfo>Stuff</xsd:appinfo> <xsd:annotation>
Yup, the attribute from the
<xsd:element> is “overwritten” and lost. And people wonder why I get bitter about these things. Always follow the rule of thumb: anytime that you do something “crafty” (such as updating the annotation to include the “annotations” (non-native attributes) from the parent element) you’re shooting yourself in the foot.
XSObject have a
XSObjectList getNonNativeAttributes() where the
XSObjectList contains perhaps
XSNonNativeAttribute objects, I don’t know. But that would have certainly saved me a few hours.
This is continued in More on XSD, PSVI and non-native attributes.