Hi Wolfgang,
Thank you for your reply.
It seems as if an element can have a type determined from a value of
its attributes, attributes in that element should also be able to have
their types determined by other attributes of the element.
Here is a simple example. The key, and currently unsupported (cant
validated), type definition is the type-type simple type for the type
attribute of the res element, in the schema sample below..
The exact syntax (ex: within an xs:restriction) is not that important,
it is really the fact that the attribute type is to be validated
according to attribute value(s) or xpath boolean function, in the
element, just as is currently possible for the element type.
Of course, attribute types still need to be simple types, and the
context is defined by the enclosing element, just as for the element
value.
<xs:schema elementFormDefault="qualified"
attributeFormDefault="unqualified" vc:minVersion="1.1">
<xs:element name="res">
<xs:complexType>
<xs:attribute name="id" type="identifier" use="required"/>
<xs:attribute name="class" type="class-type" use="required"/>
<xs:attribute name="type" type="type-type"/>
<xs:attribute name="description" type="xs:string"/>
<xs:anyAttribute/>
</xs:complexType>
<xs:simpleType name="identifier">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[0-1A-Za-z]\.[0-1A-Za-z]\.[0-1A-Za-z]"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="class-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="concept"/>
<xs:enumeration value="thing"/>
<xs:enumeration value="being"/>
<xs:enumeration value="reference"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="type-type">
<xs:restriction base="xs:NMTOKEN">
<xs:alternative test="@class = 'thing'" type="thing-type"/>
<xs:alternative test="@class = 'being'" type="being-type"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="thing-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="object"/>
<xs:enumeration value="place"/>
<xs:enumeration value="conveyor"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="being-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="mineral"/>
<xs:enumeration value="vegetable"/>
<xs:enumeration value="animal"/>
<xs:enumeration value="spiritual"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>.
2017-08-03 22:43 GMT-05:00 Wolfgang Laun
wolfgang(_dot_)laun(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>:
The definition of a simple type can make use of features such as union and
facets. It would help if you would provide an example of what you are
missing.
-W
On 4 August 2017 at 05:02, Andre Cusson akhu01(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi,
I am reaching out to this list, as I did not succeed in finding the
answer in the archives, the web or even in the specs, hoping that
someone here, possibly having contributed to the specs, may know
better.
Please forgive me if either I have not found what I should have or if
this question would have been better asked elsewhere.l
Essencially, the question is something like " how can conditional
(e.g. alternative) attribute types be defined in xsd.?
If the answer is that "it just can't", or that "the feature is not
supported", I would appreciate understanding "why?", especially as it
seems that attribute nodes are nodes, that nodes can have types and
that attributes types are types.
There seems to be important use cases that would require the feature,
as well as straight orthogonal design.
Thank you,
Akhu
XSL-List info and archive
EasyUnsubscribe (by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--