- From: Mukul Gandhi <gandhi.mukul@gmail.com>
- Date: Sun, 3 Jul 2011 12:17:28 +0530
- To: XMLSchema at XML4Pharma <XMLSchema@xml4pharma.com>
- Cc: mlcook@wabtec.com, xmlschema-dev@w3.org
I was actually playing earlier with writing a schema, as follows (only schema fragments shown, describing properties of a "book"): <xs:element name="pubyear" type="PUB_YEAR" minOccurs="0"/> <xs:attribute name="pubyear" type="PUB_YEAR"/> <xs:simpleType name="PUB_YEAR"> <xs:restriction base="xs:gYear"> <xs:explicitTimezone value="prohibited"/> </xs:restriction> </xs:simpleType> I wanted that, both of following instances should be allowed: <book pubyear="2005"> ... </book> <book> ... <pubyear>2005</pubyear> ... </book> i.e allowing XML instance writers to have 'pubyear' either as an attribute, or as a child element of "book". One of these is necessary, but both of these are not allowed. To enforce such a constraint, I found XML Schema 1.1 assertions to be useful (as follows): <xs:assert test="count(@pubyear | pubyear) = 1"/> PS: xs:explicitTimezone is also XSD 1.1 specific. And I found the use-case mentioned in this thread, similar to that mentioned above, and thought of sharing the thoughts here. I hope this is useful. On Fri, Jul 1, 2011 at 2:04 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote: > The suggestion of using assertions in this case, was not to say that > this method is best by design. Assertions seem to solve the "alias" > creation problem been mentioned. > > The best design may be (as suggested by Jozef & Mike) to keep your > schema same (it doesn't look good design to define two attributes in > schema, for one problem domain concept), and write a transformation > (XSLT is good for this need) pre-process step to convert one attribute > to another (as required by your original schema). -- Regards, Mukul Gandhi
Received on Sunday, 3 July 2011 06:48:23 UTC