OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why Are Schemas Hard?

Bullard, Claude L (Len) wrote:
> Just an aside.  There is an excellent article from
> Donald Smith at http://www.xml.com/pub/a/2001/08/22/easyschema.html
> on the mysteries of the Schemas type tree.  It doesn't take
> up the issues of namespace, binding vs validating etc. but it
> makes it much easier to understand how to do some fundamental
> work with schemas that befuddled some of us for awhile.
> Good Work, Mr. Smith!

Seconded.  A good article.

It goes a long way towards anwering the question in the
Subject: line, too.   When I figured out that the sample
XSD fragment

| <complexType name="myNewNameType">
|     <complexContent>
| 	<restriction base="anyType">
| 	    <sequence>
| 		<element name="name" type="string" />
| 		<element name="location" type="string" />
| 	    </sequence>
| 	    <attribute name="position" type="string" />
| 	</restriction>
|     </complexContent>
| </complexType>
| <element name="employee" type="dc:myNewNameType" />

means, basically,

    <!ELEMENT employee 	(name, location) >
    <!ATTLIST employee
    	position CDATA #IMPLIED >
    <!ELEMENT name	(#PCDATA) >
    <!ELEMENT location	(#PCDATA) >

I said to myself, "complexType?  That's not a complex type.
Now *this*

    (<^>) :: P ((a -> b) -> c -> d -> e)
          -> P ((f -> g) -> d -> d -> b)
	  -> P (((a,f) -> g) -> c -> d -> e)	[*]

is a complex type!"

The 'employee' definition only *looks* complex when it's
written in W3C XML Schema notation.

--Joe English