XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Use xsd to specify multiple instances of existing element

Pete,
as you said: you've provided me with a documented version of what
doesn't work.  Thanks for putting the time in.  I'm afraid that
simplicity is one of the guiding principles in my design, and
introducing xsi appears a step too far.

On reflection it does appear that what trying to do isn't possible in
xsd.  What I'm l trying to do is quite within the specification and
intentions of Atom, and specifying the guidelines in a
computer-enforceable form appears invaluable when it comes to  data
exchange between systems.

This begs the point:  how do other systems enforce tight compliance to
an Atom-based data exchange spec (such as all of those google data
APIs)?

cheers,
Ian

On Mon, Sep 22, 2008 at 3:24 PM, Pete Cordell <petexmldev@codalogic.com> wrote:
> Original Message From: "Rick Jelliffe" <rjelliffe@allette.com.au>
>
>> xsi:type addresses his issue. All it does is say "look what
>> I found", with admittedly clever, rococo elaborateness, not "here is what
>> you can do".
>
> No need for the attitude.  After all, most things in XML schema require
> clever, rococo elaborateness!
>
> And rather than directly answering Ian's concern, I was more directly
> motivated by answering your comment:
>
>> To make this work, don't you have to define the <entry> element to use
>> wildcards? For example (loosely)
>
> by trying to say that you don't need wildcards to make it work.
>
> Fleshing out the XSD a bit more, I get something like:
>
> <xs:element name='category' type='categoryType' />
>
> <xs:complexType name='categoryType' abstract='true'/>
>
> <xs:complexType name='privacy'>
>   <xs:complexContent>
>       <xs:extension base='categoryType'>
>           <xs:attribute name='scheme' type='xs:string'
> fixed='http://dig.com/privacy'/>
>           <xs:attribute name='term'>
>               <xs:simpleType>
>                   <xs:restriction base='xs:string'>
>                       <xs:enumeration value='open'/>
>                       <xs:enumeration value='private'/>
>                   </xs:restriction>
>               </xs:simpleType>
>           </xs:attribute>
>       </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
>
> <xs:complexType name='fishingType'>
>   <xs:complexContent>
>       <xs:extension base='categoryType'>
>           <xs:attribute name='scheme' type='xs:string'
> fixed='http://dig.com/fishingType'/>
>           <xs:attribute name='term'>
>               <xs:simpleType>
>                   <xs:restriction base='xs:string'>
>                       <xs:enumeration value='coarse'/>
>                       <xs:enumeration value='open'/>
>                   </xs:restriction>
>               </xs:simpleType>
>           </xs:attribute>
>       </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
>
> Which, at the category element level, I think does meet Ian's requirements,
> _IF_ he his prepared to accept the presence of the xsi:type.  Personally I
> don't think he can, but I don't know that until I ask him.
>
> It also fails to ensure that a category element of type privacy must be
> followed by a category element of type fishingType (wider discussion for
> those interested in learning something from the list: you can obviously say
> that there must be two category elements within an entry element, but you
> can't enforce their types).
>
> Even if it is not something he is not prepared to do, it is a documented
> avenue of what does not work, which in engineering can be as important as
> documenting what does work!
>
> So, my answer to Ian is you can't exactly do what you want using XSD.  There
> are some ways you can get close to it, most of which Rick has described.
> What I've presented is some discussion material about one of the ways
> suggested, and by discussing it it is not implied that that is a proposed
> solution.
>
> I am definitely not saying "look at my great clever solution.  Aren't I
> wonderful?"
>
> Regards,
>
> Pete Cordell
> Codalogic Ltd
> Interface XML to C++ the easy way using XML C++
> data binding to convert XSD schemas to C++ classes.
> Visit http://www.codalogic.com/lmx/ for more info
>
> ----- Original Message ----- From: "Rick Jelliffe"
> <rjelliffe@allette.com.au>
> To: <xml-dev@lists.xml.org>
> Sent: Monday, September 22, 2008 2:33 PM
> Subject: Re: [xml-dev] Use xsd to specify multiple instances of existing
> element
>
>
>>
>> Pete Cordell wrote:
>>>
>>> I think what Andrew is suggesting is something like:
>>>
>>> <xs:element name='category' type='categoryType' />
>>>
>>> <xs:complexType name='categoryType' abstract='true'>
>>>   ...
>>>
>>> <xs:complexType name='privacy'>
>>>   <xs:complexContent>
>>>       <xs:extension base='categoryType'>
>>>           ...
>>>
>>> <xs:complexType name='fishingType'>
>>>   <xs:complexContent>
>>>       <xs:extension base='categoryType'>
>>>           ...
>>
>> But this does not meet Ian's requirement, which was to constrain that the
>> first <category> can have some attribute values,
>> and the second <category> can have some others.  I don't see that xsi:type
>> addresses his issue. All it does is say "look what
>> I found", with admittedly clever, rococo elaborateness, not "here is what
>> you can do".
>>
>> Cheers
>> Rick Jelliffe
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>



-- 
Ian Mayo
PlanetMayo Ltd


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS