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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Schema concepts

[ Lists Home | Date Index | Thread Index ]
  • From: "Matthew Gertner" <matthew@praxis.cz>
  • To: "'XML-Dev Mailing list'" <xml-dev@xml.org>
  • Date: Thu, 17 Feb 2000 11:19:26 +0100

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. We computer scientists know that 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 crazy about the way that SOX solved 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 fantastic if some areas could be simplified without significant loss of power.

Matthew





 

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

Copyright 2001 XML.org. This site is hosted by OASIS