Michael - you've asked for feedback about whether redefine should be
deprecated.  I believe it should.

 

I believe that the primary purpose for which schemas are written is an
attempt to facilitate automated data exchange between computer systems.
Features which in practice provide an "impedance" to the smooth
automation of data exchange are bad.  This email thread provides a
classic illustration of a feature which has resulted in troubled and
problematic implementation.

 

With regard to this discussion creeping onto other features such as
complex type derivation by restriction, I don't think it is particularly
helpful of you to suggest that people stick to programming languages
which support the same data structure concepts as XML Schema!  Picking
up your own point from another email on this thread, schema is widely
used as a data interchange format even though it originated in document
markup.  Data interchange involves sending and receiving systems, and to
my mind an interchange definition which aims at facilitating smooth
automation should dovetail reasonably easily with technologies commonly
used - the words "cart", "horse", "tail" and "dog" spring to mind! I
think schema has often been criticised as over-complicated and
over-sophisticated.  Maybe definition of some subset of schema
facilities for common data interchange would help in this whole area,
although obviously attempting such an exercise would not be an easy one.


 

From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...]
On Behalf Of Michael Kay
Sent: 01 October 2009 23:53
To: 'XMLSchema at XML4Pharma'; xmlschema-dev@w...
Subject: RE: Escalation mechanism for different interpretation of W3C
XML-Schema specification ?

 

Just for the record (though it only really confirms the point that there
are differing interpretations), I implemented the XSD 1.0 specification
without the benefit of knowing anything about the intent of the WG
beyond what was written in the spec, and I came to the conclusion that
there was only one way of interpreting the rule about xsd:redefine being
"pervasive". But then I also came to the conclusion that other parts of
the schema composition rules had to be treated as loose statements of
intent which didn't cover all contingencies.

 

I would certainly advise against using xs:redefine in an industry schema
specification. Its only possible justification in my view is to define a
variant of a schema produced by a third party. And for that use case, I
think it only works unambiguously if that schema uses a single target
namespace throughout.

Michael Kay

Saxonica

	
________________________________


	From: xmlschema-dev-request@w...
[mailto:xmlschema-dev-request@w...] On Behalf Of XMLSchema at
XML4Pharma
	Sent: 29 September 2009 12:24
	To: xmlschema-dev@w...
	Subject: Escalation mechanism for different interpretation of
W3C XML-Schema specification ?

	We, the CDISC XML-Tech Governance Team (and other CDISC teams)
have developed a number of extensible standards for exchange of clinical
data and for submitting information to the regulatory authorities (FDA).

	CDISC is a Standardization Organization active in the healthcare
world.

	Our extension mechanism is based on the "import" and "redefine"
elements of XML-Schema.

	We now have a serious dispute with one technology vendor
(Altova) about the way "import" and "redefine" are used. Instance files
of one of our extensions (so-called "define.xml") validate well in all
major validators and XML-editors, except for the products of this one
vendor.

	When confronted with this result, the reaction of Altova
essentially is that "Altova is right, all others are wrong". The dispute
and discussion with Altova can be followed at:
	http://www.altova.com/forum/default.aspx?g=posts&m=1000005665

	The issue were not so serious if it were not that our standard
"define.xml" is a standard for submission of information to the
regulatory authorities, and these are (mostly) using the Altova product
for validation.

	We now want to escalate the issue to the W3C itself, and would
like to know what the mechanism is to do so.

	Jozef Aerts
	CDISC XML-Tech Governance Team


Disclaimer: 
 
The contents of this E-mail plus any attachment is intended for the use of the 
addressee only and is confidential, proprietary and may be privileged. It will not be 
binding upon Trace Group or any group company (Trace).  Opinions, conclusions, 
contractual obligations and other information in this message in so far as they relate to 
the official business of Trace must be specifically confirmed in writing by Trace. If you 
are not the intended recipient you must not copy this message or attachment, use or 
disclose the contents to any other person, but are requested to telephone or E-mail 
the sender and delete the message and any attachment from your system. Trace 
takes all reasonable precautions to ensure that no virus or defect is transmitted via 
this e mail, however Trace accepts no responsibility for any virus or defect that might 
arise from opening this E-mail or attachments.