Re: Complex Type Definition Schema Component (Structures)

Jeff Rafter writes:

>> I think that section 3 is a solid roadmap for 
>> starting a set of classes

That's great to hear, thank you.

>> I was merely commenting that if it were a goal this 
>> may be one of the few changes I would shout for.  That
>> being said, and it not being a goal, is there a strong 
>> reason that such a small modification should not be made

I think I am correct that you are referring here to your original concern 
about the "promiscuous polymorphism" in the schema component properties, 
such as those that mix integers, strings, sets, etc. in the allowed values 
for a single property.  First of all, it really is too late to make such a 
change without significantly impacting what is (we hope) our schedule. 
Furthermore, as I mentioned in my original response to you [1], "The sort of aggressive polymorphism used in the specification makes it 
more compact."  It also makes clearer which choices are truly exclusive 
and which can coexist.  If we broke individual properties into two or 
three pieces, we would have to carefully specify the interdependencies.

Furthermore, while you and I probably program in similar languages and 
styles, the schemas specification is not focused on any particular 
implementation idiom.  There are languages and programming styles in which 
the component values could be expressed quite straightforwardly.  Indeed, 
although it would be inefficient and in that sense undesirable, one could 
easily imagine a Java programming style in which every property value was 
a full-fledged object (as opposed to a built-in type such as int).  Some 
of the object might be collections, etc. and dynamic typing using 
interfaces could easily be used to determine at runtime the exact nature 
of the value stored for aproperty. 

Consider:

        // singleton: there will be only one 
        // instance of following class
        class GlobalMarker extends Object implements GlobalScope {};

        // used for all complex type def components
        class ComplexTypeDefinition extends Object  {};

        class AttributeDeclaration {
                ..
                Object scope;  // takes instance of
                                    // GlobalMarker or 
                                    // ComplexTypeDefinition
                ..
        };

        if (scope instanceOf GlobalScope) {} 
        else if (scope instanceOf  ComplexTypeDefinition ) {}...

Indeed, one could argue that this would be the purest and most 
straightforward implementation (if slow on most Java VMs), with all the 
more verbose variations viewed as optimizations.  So, I think that for all 
those reasons we should and will stick with the status quo.  I am sorry 
that this decision will obviously somewhat disappoint you.

>> Either way I am very happy overall, despite 
>> some moanings-- I think it is a great spec.

I am sure I speak for many of those on workgroup when I say, thank you so 
much!  This is obviously a complex specification intended to meet the 
needs of quite a broad range of users.  Not surprisingly, the 
specification has its critics regarding both the nature of the design and 
characteristics of the presentation in the specification document. 
Encouragement like this is much appreciated, particularly coming from 
someone like you who has obviously been through the specification 
carefully.  Thank you.

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Feb/0214.html

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Monday, 5 March 2001 16:34:55 UTC