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

Jozef Aerts writes:

> So JSON may be a good alternative.

I would never discourage you from looking for the best language to meet 
your needs, and JSON is in many respects simpler than XML.  That said, 
keep in mind that JSON is fundamentally aimed at what we informally call 
"data", I.e. roughly the sorts of things that fit well into a Java, C, or 
(of course) Javascript structure.  JSON is typically not good at dealing 
with structured documents, in which multiple paragraphs must be kept in 
order, and mixed with other structures such as address fields, approval 
markings, signatures, or text formatting information.  It's not that you 
can do that with JSON, but in complex cases you wind up doing a lot of 
work in nonstandard ways. 

So my guideline would be:  if you're really dealing with fairly pure 
"data", take your pick according to the skills of your programmers, the 
tooling you want to use, and especially the expectations of those with 
whom you will be sharing the data.  If you have lots of document-style 
information to deal with (and there are sort of vague estimates that the 
vast majority of information that computers deal with is more like that 
these day), then I'd think twice before using something like JSON. 
Instead, I'd go with a custom XML vocabulary, or if you prefer, an Open 
Document Format file.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"XML4Pharma" <info@XML4Pharma.com>
10/03/2009 06:13 AM
Please respond to "XML4Pharma"
 
        To:     "Michael Kay" <mike@saxonica.com>, "'Dennis Sosnoski'" 
<dms@sosnoski.com>, <noah_mendelsohn@us.ibm.com>
        cc:     "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>, 
<xmlschema-dev@w3.org>
        Subject:        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 15:19:18 UTC