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

Re: XML Schema question

  • From: Stephen Green <stephengreenubl@gmail.com>
  • To: XML Developers List <xml-dev@lists.xml.org>
  • Date: Wed, 2 Mar 2011 09:07:45 +0000

Re:  XML Schema question
I came across this while trying to subset WXS and explain the use of
the subset and it is partly a curiosity to me but partly it raises questions
about what is minimally required for maximum simplicity with maximum
utility in a MicroXSD subset:

Are these three ways to do exactly the same thing, i.e. defined precisely
the same constraints on an XML instance (in this case a single element
named 'Greeting' of datatype 'string' <Greeting>Hello World</Greeting>)?

1.
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified" elementFormDefault="qualified">
     <element name="Greeting">
         <complexType>
             <simpleContent>
                 <extension base="string"/>
             </simpleContent>
         </complexType>
     </element>
</schema>

2.
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified" elementFormDefault="qualified">
     <element name="Greeting">
         <simpleType>
             <restriction base="string"/>
         </simpleType>
     </element>
</schema>

3.
 <schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified" elementFormDefault="qualified">
     <element name="Greeting" type="string"/>
</schema>

I kind of tend to want to remove such redundancy unless there is some
value keeping three ways to do the same thing. I guess a processor
trying to take of advantage of only having to conform to the conformance
target of the subset might prefer to only have to handle one kind of rep-
resentation in the markup. I prefer to prune out the attribute 'type' because
it introduces complications for my metaschema but I'm inclined to prune
away the simpleType as a child of an element and just keep simple type
for an attribute. Then a processor need only expect 'complexType' as
an element child. Does this make sense? Option 1 seems to give most
extensibility so why bother with 2 and 3?

Maybe some of the redundancy could have been removed from WXS
but I guess it is too late now to make big changes in any future version.

Not having to handle multiple namespaces makes a great difference
to the pain of explaining the subset - makes me happy about MicroXML.

Cheers


----
Stephen D Green






On 01/03/2011, Stephen Green <stephengreenubl@gmail.com> wrote:
> OK, maybe it is impossible to get it perfect but I updated
> the MicroXSD subset of W3C XML Schema and gave it a
> version number '2012'  - "future-looking", "going-forward" :-)
>
> I have posted it on my blog
> http://stephengreenxml.blogspot.com/2011/02/microxsd.html
>
> Comments welcome
>
> ----
> Stephen D Green
>
>
>


[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.