Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ?

In our extension schemas, we only use "redefine" to ADD extra attributes and 
elements (in a separate namespace), not to change or remove any existing 
ones.

One of my positive surprises with the way we implemented it, is that a XML 
data binding like XMLBeans had no problem at all working with it: it was 
very easy to derive all classes from our schemas including the "redefine".

Dennis suggested to have a look at JSON, which I did.
This might be a very good idea for a format for submitting information/data 
to the FDA.
The problem at the FDA is that there is almost noone there with a basic 
understanding of XML, and those who have left the FDA to become a well-paid 
consultant. Some departments at the FDA have the greatest difficulty to 
validate even very simple XML documents.
The FDA is currently planning to switch to HL7-v3-XML messages for 
electronic submissions of data to the agency. As HL7-v3-XML is highly 
complex (and even not good XML i.m.o.) I think this will lead to disaster. 
So JSON may be a good alternative.
I had a quick look, but JSON does not have some data types like date, time 
and dateTime. Would be nice if they had ...

Best,

Jozef Aerts
XML4Pharma


----- Original Message ----- 
From: "Michael Kay" <mike@saxonica.com>
To: "'Dennis Sosnoski'" <dms@sosnoski.com>; <noah_mendelsohn@us.ibm.com>
Cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>; "'C. M. 
Sperberg-McQueen'" <cmsmcq@blackmesatech.com>; <xmlschema-dev@w3.org>
Sent: Saturday, October 03, 2009 12:43 AM
Subject: RE: Escalation mechanism for different interpretation of W3C 
XML-Schema specification ?


>
> While I think many of your criticisms of xs:redefine and complex type
> restriction and indeed xs:override are valid, I personally don't accept 
> the
> premise that XSD should be constrained or influenced by the data typing
> paradigms of conventional programming languages. XML and XSD are first and
> formost intended for designing hierarchic document structures (a 
> discipline
> with a far longer tradition than programming), and the fact that
> conventional programming languages don't support such structures very well
> means in my view that it's best to switch to languages that do.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>> -----Original Message-----
>> From: xmlschema-dev-request@w3.org
>> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Dennis Sosnoski
>> Sent: 02 October 2009 23:10
>> To: noah_mendelsohn@us.ibm.com
>> Cc: XMLSchema at XML4Pharma; C. M. Sperberg-McQueen;
>> xmlschema-dev@w3.org
>> Subject: Re: Escalation mechanism for different
>> interpretation of W3C XML-Schema specification ?
>>
>> Hi Noah,
>>
>> IMHO both xs:redefine and xs:complexType restriction should
>> be eliminated. With respect to the increasingly important
>> area of XML data binding for programming languages, redefine
>> and complexType restriction are generally ignored for the
>> simple reason that they have no equivalent in terms of data
>> models. The object oriented programming equivalent of
>> complexType restriction would be to define a subclass by
>> eliminating information from the parent class, which is a
>> bizarre concept in programming terms - if you want a limited
>> representation which is not supported by the current data
>> model you either refactor the data model to support the
>> particular subset you want or use a representation which has
>> more features than you need, with semantic constraints on the usage.
>> There are times when this limitation of object oriented
>> programming is inconvenient, but I suspect the vast majority
>> of developers would agree that the benefits in terms of clean
>> data models more than outweigh the inconvenience.
>>
>> Beyond this, the very nature of complexType restriction,
>> which requires repeating all portions of the original model
>> which are being retained, creates brittle definitions.
>>
>> redefine is an even stranger operation, effectively
>> performing surgery on an existing definition to deform it in
>> ways never intended by the original designers. One
>> consequence is that anyone looking at an instance of an XML
>> structure defined by a schema needs to be aware of other
>> schemas which may have modified the original schema definition.
>> Requiring knowledge of the entire set of schemas involved in
>> a document in order to understand one particular component of
>> the document is contrary to good design principles.
>>
>> It's hard for me to see how xs:override represents any kind
>> of improvement on redefine, so asking for feedback on
>> deprecating redefine while adding override into the mix seems
>> deliberately futile. From my point of view override suffers
>> from the same design failures as redefine, and should also be
>> eliminated.
>>
>> I realize that many uses of W3C schema are not concerned with
>> data binding, but I'd suggest that the difficulty of modeling
>> these constructs in terms of modern programming language
>> structures shows that they could be eliminated without
>> significantly harming the usefulness of schema.
>>
>>   - Dennis
>>
>> Dennis M. Sosnoski
>> XML and Web Services in Java
>> Training and Consulting
>> http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle,
>> WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>>
>>
>>
>> noah_mendelsohn@us.ibm.com wrote:
>> > I strongly urge you to read Michael Sperberg-McQueen's note
>> carefully.
>> > While, as noted below, some of my preferences for resolving
>> > ambiguities happen to be different from his, I believe that
>> his email
>> > very accurately and carefully summarizes the state of play on this
>> > issue.  Let me just quote and comment on a few sections of
>> Michael's note:
>> >
>> >
>> >> The XSD 1.0 specification does not explicitly address the
>> case when
>> >> the same schema document in referenced both directly (via
>> import or
>> >> include) and indirectly (via redefine).  The rules for
>> import specify
>> >> that the components imported via the import or include should be
>> >> present in the resulting schema; the discussion of
>> redefine says that
>> >> the effect of redefine is pervasive.
>> >>
>> >
>> > Yes, that's what it says, and it's contradictory.
>> >
>> >
>> >> Some readers interpret this to mean that the
>> pervasive-redefinition
>> >> rule overrides, or modifies the effect of, the import and include
>> >> rules.  On this reading the schema is legal and the components are
>> >> present in their redefined form (and only that form).
>> This reading
>> >> effectively attaches to the rules for include and import
>> an unspoken
>> >> exception to the effect that the components imported or
>> included are
>> >> present in the resulting schema unless they are redefined by some
>> >> other schema document reference.
>> >>
>> >> Other readers interpret the rules as requiring that the
>> components in
>> >> question should be present both in their original and in their
>> >> redefined form, which means that the schema violates the rule that
>> >> there must be at most one component of any kind with a
>> given expanded
>> >> name, and thus that the schema should be rejected.
>> >>
>> >
>> > Yes, those are at least two of the widely held positions as to what
>> > was "really" intended, and I don't think I'm aware of any others.
>> >
>> >
>> >> It is my personal belief that the most plausible interpretation of
>> >> the specification is the latter; as you have observed, at
>> least some
>> >> implementors disagree and prefer the other interpretation.
>> >>
>> >
>> > I happen to be one of the others who would prefer that the
>> redefine be
>> > pervasive, but the important point here is that either
>> interpretation
>> > is plausible, and we agree on that.
>> >
>> >
>> >> The inability of the XML Schema working group to agree on
>> a normative
>> >> interpretation of XSD 1.0 has led to the agreement to
>> deprecate the
>> >> redefine element in XSD 1.1.
>> >>
>> >
>> > Here, I'd like to add one bit.  While Michael is correct that the
>> > working group has "agreed" on this, some of us joined in that
>> > agreement with some hesitancy, because we believe that
>> <redefine> has
>> > seen widespread use, including in cases that do not trigger (or at
>> > least do not as clearly
>> > trigger) the ambiguities that are causing trouble here.
>> So, in light
>> > of those concerns, the working group also agreed to make the
>> > deprecation of <redefine> a so-called Priority Feedback issue.
>> > Quoting from the working draft [1]:
>> >
>> > ----
>> > Note: The redefinition feature described in the remainder of this
>> > section is .deprecated. and may be removed from future versions of
>> > this specification. Schema authors are encouraged to avoid
>> its use in
>> > cases where interoperability or compatibility with later
>> versions of
>> > this specification are important.
>> >
>> > Editorial Note: Priority Feedback Request
>> >
>> > The Working Group requests feedback from readers, schema authors,
>> > implementors, and other users of this specification as to the
>> > desirability of retaining, removing, deprecating, or not
>> deprecating
>> > the use of <redefine>. Since the <override> facility
>> provides similar
>> > functionality but does not require a restriction or
>> extension relation
>> > between the new and the old definitions of redefined
>> components, the
>> > Working Group is particularly interested in learning
>> whether users of
>> > this specification find that requirement useful or not.
>> > ----
>> >
>> > So, if any readers of this thread have opinions on the plan to
>> > deprecate, the Schema Working group would welcome hearing
>> about them.
>> > I think it's worth noting that this thread has already made clear
>> > that: 1) this is a known area of complexity and the working
>> group has
>> > already tried and so far failed to find an easy resolution
>> acceptable
>> > to all; 2) there are incompatibilities in widely deployed
>> > implementations, so any clear resolution is quite likely to make
>> > someone with an investment in code very unhappy.  That's
>> not to say I
>> > wouldn't like it cleaned up;  indeed, I'm among those who put many
>> > months into trying a few years ago (as did Michael). I'm
>> just pointing
>> > out that our choices may be to deprecate or undeprecate, but going
>> > further to remove the ambiguity is likely to be a
>> significant effort
>> > that will introduce incompatibilities for at least
>> somebody.  Maybe or
>> > maybe not we could find a way to warn people off from the most
>> > troublesome cases, but I know that Michael and perhaps others will
>> > correctly point out that the whole conceptual framework for this
>> > "composition" function is sufficiently shaky in the current drafts
>> > that any fix short of a complete rewrite is likely to leave
>> things in a messy state.
>> >
>> > Noah
>> >
>> > [1] http://www.w3.org/TR/xmlschema11-1/#modify-schema
>> >
>> > --------------------------------------
>> > Noah Mendelsohn
>> > IBM Corporation
>> > One Rogers Street
>> > Cambridge, MA 02142
>> > 1-617-693-4036
>> > --------------------------------------
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>

Received on Saturday, 3 October 2009 10:14:47 UTC