Re: [xsl] alternate attribute types in xsd

Subject: Re: [xsl] alternate attribute types in xsd
From: "Andre Cusson akhu01@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 11 Aug 2017 02:21:54 -0000
Dear Dr Stellmann,

While it seems unfortunate that XSD (e.g. 1.1) does not support
conditional attribute types, some subscribers to this list have
suggested interesting workarounds.
The RELAX NG approach suggested by Syd Bauman, seems especially
elegant, expressive, and powerful.
Unfortunately, the availability of common high performance RELAX NG
validators seems like an issue for this application.

While seemingly somewhat deliciously devious, your XSD approach is
certainly very interesting.
I would be just about to use it but there seems to be one more
consideration that was unfortunately not obvious from the simplified
example I provided.
I would like to it submit to you, and others possibly, in the hope
that you could further help resolve it.

The issue is that the res element in the model I am trying to put
together has more attributes, including 4 more, currently, for which,
like the @type attribute in the example, the attribute type also
depends on the value of the @class attribute.
Luckily, for now still, I do not need cascading  conditional types, as
all five of these attributes depend on the value of the same @class
attribute.
In other words, there are attributes like @status, @phase, @mode,
@group, for example, which are enumerations also, just like for the
@type attribute, and that each depend on the value of the @class
attribute.

For example, for the @phase attribute, there could be a
thing-phase-type as well as a being-phase-type, whether @class="thing"
or @class="being", and so on.

I can imagine that I could possibly define square(# of
conditional-attributes, e.g. 25) extension types and try to figure out
some way to assign them some, but it seems less obvious than I would
hope.

Is there a way to express this type of conceptually conditional
attributes in XSD?

If so, how would you handle having just one more @class dependent
attribute type (e.g. @phase)?

Thank you for your support, your time, and for an interesting and
creative example use of XSD.

Regards,

ac




2017-08-06 23:29 GMT-05:00 Dr. Patrik Stellmann
patrik.stellmann@xxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>:
> You can get the desired behavior already with the current capabilities -
just by providing alternative types for the res element:
>
>
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
elementFormDefault="qualified" attributeFormDefault="unqualified">
>
>   <xs:element name="res" type="res-base">
>
>     <xs:alternative test="@class = 'thing'" type="res-thing"/>
>
>     <xs:alternative test="@class = 'being'" type="res-being"/>
>
>   </xs:element>
>
>   <xs:complexType name="res-base">
>
>     <xs:attribute name="id"/>
>
>     <xs:attribute name="class" type="class-type" use="required"/>
>
>   </xs:complexType>
>
>   <xs:complexType name="res-thing">
>
>     <xs:complexContent>
>
>       <xs:extension base="res-base">
>
>         <xs:attribute name="type" type="thing-type"/>
>
>       </xs:extension>
>
>     </xs:complexContent>
>
>   </xs:complexType>
>
>   <xs:complexType name="res-being">
>
>     <xs:complexContent>
>
>       <xs:extension base="res-base">
>
>         <xs:attribute name="type" type="being-type"/>
>
>       </xs:extension>
>
>     </xs:complexContent>
>
>   </xs:complexType>
>
>   <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="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:schema>
>
>
>
>
>
> Patrik
>
>
>
>>
>
> ------------------------------------------------------------------
>
> Systemarchitektur & IT-Projekte
>
> Tel: +49 40 33449-1142
>
> Fax: +49 40 33449-1400
>
> E-Mail: mailto:Patrik.Stellmann@xxxxxxxxx
>
>
>
> -----UrsprC<ngliche Nachricht-----
>
>> Von: Andre Cusson akhu01@xxxxxxxxx [mailto:xsl-list-
>
>> service@xxxxxxxxxxxxxxxxxxxxxx]
>
>> Gesendet: Freitag, 4. August 2017 21:59
>
>> An: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>
>> Betreff: Re: [xsl] alternate attribute types in xsd
>
>>
>
>> 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.laun@xxxxxxxxx
>
>> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>:
>
>> > 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@xxxxxxxxx
>
>> > <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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)
>
>>
>
>
>
> GDV Dienstleistungs-GmbH
>
> GlockengieCerwall 1
>
> D-20095 Hamburg
>
> www.gdv-dl.de
>
>
>
> Sitz und Registergericht: Hamburg
>
> HRB 145291
>
> USt.-IdNr : DE 205183123
>
>
>
> GeschC$ftsfC<hrer:
>
> Dr. Jens Bartenwerfer
>
> Michael Bathke
>
> Fred di Giuseppe Chiachiarella
>
> Thomas Fischer
>
>
>
> Aufsichtsratsvorsitzender: Werner Schmidt
>
>
>
> ------------------------------------------------------------------
>
> Diese E-Mail und alle AnhC$nge enthalten vertrauliche und/oder rechtlich
geschC<tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtC<mlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die
unbefugte Weitergabe der E-Mail ist nicht gestattet.
>
>
>
> This e-mail and any attached files may contain confidential and/or
privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorised copying, disclosure or distribution of
the material in this e-mail is strictly forbidden.

Current Thread