- 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