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

RE: Schema concepts

  • From: "Matthew Gertner" <matthew@p...>
  • To: <xml-dev@x...>
  • Date: Thu, 17 Feb 2000 17:26:10 +0100

RE: Schema concepts
Title: RE: Schema concepts

Stefan Haustein wrote:
> Doing everything twice is not what I want to do.
> It is ok to me if XML schema lets me do that,
> but I do not want to be forced to. Do
> you not agree that it should always be a
> design goal for standards to keep them as
> simple as possible (as far as feasible without
> losing the objectives)? I claim that the artificial
> type/element distinction makes xml schema more
> complicated than needed.

This is an incredibly important discussion about an incredibly important part of any future XML architecture. I am glad to see that Stefan is raising these issues. As any computer scientist knows, having multiple ways to do the same thing is bad, unless they are significantly differentiated somehow (e.g. a flexibility/complexity tradeoff). Yes, I'm a C++ programmer, so it's no wonder that I am confused. Nevertheless, I'd like to reiterate Stefan's question:

If we were to eliminate from XML schema:
1) The distinction between element and complex types
2) The (explicit) distinction between inheritance by extension and by restriction
3) The need to specify an equivClass for substitutability (using implicit subtype relationships instead)

What do we lose? What can't I do? Saying that there is a theoretical distinction here is not enough, because these aspects significantly complicate the spec. I suppose that simplicity really is a goal, and that everyone realizes that every drop of extra complexity makes the chance that the spec will not achieve real, broad adoption slightly larger. The fact that people are already talking about a subset, before the spec itself is even blessed as a Recommendation, is a dangerous sign indeed.

Michael Anderson wrote:
> Subsequent responses to me pointed out that I should have written
> <C>
>   <A xsi:type="Btype"> B stuff in here </A>
> </C>
> I would call this instance instance 2.

This is another one that has me a bit baffled. I wasn't entirely crazy about the way that SOX solves the issue of polymorphism either, but I know that there are some less-than-obvious considerations. Can someone clarify? Why can't I just embed the B and have the processor keep track of subtyping relationships?

Thanks in advance for any enlightment. I find the current spec intimidatingly complex even for an XML and OO programming expert. It would be a big win if some areas could be simplified without significant loss of power.

Matthew


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.