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