Donal K. Fellows wrote:
Christopher Smith wrote:
I don't know if others are having this issue, but my tooling doesn't like all the xsd:any that show up in the FactoryResourceAttributesDocumentType. [...] That makes two xsd:any in one complex type, which is one too many in my opinion.
Can we perhaps refactor this type? I've also noticed that I can only provide one OperatingSystem, CPUArchitecture, etc, etc, which doesn't allow me to list the elements of my cluster. [...] Even if we don't refactor like I suggested, we need to control the xsd:any's.
I've hit this before and it is distinctly unpleasant. The problem is that the XML Schema specification is very weak in this area; the schema working group doesn't seem to view things in quite the same way as the rest of the world. :-\
There does appear to be a way to get what you want within the model of the schema, and that is to first use complex type restriction to strip the xs:any to make a "trimmed base type", and then extend that with the extra elements, finishing off with the xs:any. The main down-sides of this are that it is ugly and who knows how anyone's tooling copes with it?
Or simply start out with a non-any complexType that both the basic and full resource attributes types extend.
Myself, I've tended to end up writing out the whole document type in full when I've had to do that sort of thing instead, and only adding the xs:any at the end by a final stage to apply it. But that's disgusting in other ways.
As a side note, this is compatible with WS-ResourceProperties 1.2, but I know that at least one implementation would have choked on it at one point since this is getting into the wilder parts of schema processing.
Now I need to floss my brain. Too much reading of W3C specs!
Donal. -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg