[Bug 7242] Type inconsistencies introduced by inheritable attributes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7242





--- Comment #7 from Peter.Geraghty@tracegroup.com  2009-09-14 11:03:27 ---
I sympathise with the WG's struggle with the request from i18n as revealed in
bug 5003  :(. Personally I think the closure of that request was actually the
correct decision, as the solution which has emerged is unsatisfactory from many
points of view.

If I could make a general point it would be a plea to consider automated
information flows in the round when designing new features.  For example, the
use case of 5003 is:

<xs:element name="annotation" type="annotationType">
  <xs:alternative test="@xml:lang='ja'" type="rubyType"/>
  <xs:alternative test="@xml:lang='en" type="glossingType"/>
...</xs:element>

This schema implies that when an instance document is ceated the creator will
include different content depending on what value of xml:lang is specified on
an ancestral node.  Behind the new feature request is an assumption that for
the creator it is significantly easier to include the appropriate content
without an explicit type identifier than it would be to include the appropriate
content with an xsi:type.  However, whilst this would save keyboard work for a
human keying in the document, in practice the creator will be a computer
program, and so the assumption that it is easier for the producer to omit the
xsi:type is spurious. On the other hand, the new feature involves significant
extra complexity for a receiving system.

My experience is that when standards in a particular area (e.g., schema) are
complicated and do not integrate easily with other standards and tools there is
an adverse effect on the ease of defining and implementing automated
information flows, not a positive one, however sophisticated or powerful the
features may be in isolation. 

It is true that producers of information are not obliged to use any particular
feature allowed by schema, but when the designer of the production of the
information has several allowed possibilities s/he may, through ignorance or
time pressures, choose options which cause difficulties for receiving systems.

Unlike a programming language, where the decision to use particular language
facilities within a project affects a single community working on that project,
XSDL is inherently involved with separate producers (who choose which language
constructs to use) and consumers who are obliged to go with the producers'
choice. These asymmetric roles affect the economics whereby the consumers bear
costs relating to producers' decisions.  They also affect overall cost and
elapsed time to production if consumers request amendments and there are
feedback iterations.  Don't forget that information flows do not begin or end
as xml documents - those documents have to be produced by something and they
have to be processed by something.

In a nutshell, why allow multiple different ways of defining the same business
information content?  Consistency and standardisation are more important
enablers of information flow than elegance or sophistication.

Here endeth the general plea.

I have not changed the status of the fault as the current status is REOPENED
not DECIDED and I do not have an option for CLOSED - apologies for Bugzilla
ignorance if I've misunderstood comments 4 or 6.

However I understand the WG's position and I am satisfied with the response
given.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 14 September 2009 11:03:40 UTC