[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Use xsd to specify multiple instances of existing element

  • From: "Ian Mayo" <ianmayo@t...>
  • To: "Pete Cordell" <petexmldev@c...>
  • Date: Mon, 22 Sep 2008 15:35:43 +0100

Re:  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@c...> wrote:
> Original Message From: "Rick Jelliffe" <rjelliffe@a...>
>
>> 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@a...>
> To: <xml-dev@l...>
> Sent: Monday, September 22, 2008 2:33 PM
> Subject: Re:  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@l...
>> subscribe: xml-dev-subscribe@l...
>> 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@l...
> subscribe: xml-dev-subscribe@l...
> 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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.