W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2007

[Bug 3075] XML 1.0 or 1.1 user override

From: <bugzilla@wiggum.w3.org>
Date: Fri, 17 Aug 2007 17:18:32 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1IM5Sy-000216-UD@wiggum.w3.org>


cmsmcq@w3.org changed:

           What    |Removed                     |Added
             Status|ASSIGNED                    |RESOLVED
           Keywords|                            |resolved
         Resolution|                            |LATER

------- Comment #6 from cmsmcq@w3.org  2007-08-17 17:18 -------
Francois, thank you for raising this issue about user overrides of
heuristics for choosing between datatypes based on XML 1.0 and 
datatypes based on XML 1.1.

The Working Group discussed this issue during today's telcon.  There
was some support for the change proposed here, but also some
opposition.  In the end, it became clear that the conflicting views
which led to the existing compromise text were both still present in
the WG and both still deeply held.

On the one hand, there are those who stress the importance of support
for XML 1.1 and point to the drawbacks of all known heuristics for
choosing automatically between XML 1.0 and XML 1.1, and who feel, with
the original poster, that the best solution is to make the SHOULD be a
MUST.  On the other side there are those who note that XSDL's
conformance rules make it feasible to write conforming processors for
very specialized applications (a minimally conforming processor, for
example, may have a hard-coded schema suitale for one particular type
of message; it's not impossible to imagine that for such a processor,
the deployment scenario is well known and really does not require user
control of the choice between XML 1.0 and 1.1, because the document
type carefully follows conventions that allow a heuristic to work.
Requiring user control in such a processor amounts to requiring either
some unnecessary work (not necessarily a great deal, but still
unnecessary), or requiring that such a processor not label itself

The verb SHOULD signals that (in the words of XSDL 1.1 Structures):

    It is recommended that conforming documents and XSDL-aware
    processors behave as described, but there can be valid reasons for
    them not to; it is important that the full implications be
    understood and carefully weighed before adopting behavior at
    variance with the recommendation.

WG members in the first group would prefer a MUST here, but are
willing to agree that a SHOULD is better than nothing at all; they may
think that there are really very seldom valid reasons for not having
user control over which version of the XML-related datatypes should be
used, but SHOULD at least signals clearly that the user override is
recommended and normally the right thing to do.  WG members in the
other group would really prefer just a MAY here (or would prefer to
say nothing at all about user overrides, on the premise that vendors
and users know their needs better than a standardization committee is
ever likely to), but they are willing to agree that a SHOULD is better
than nothing at all: they may think that there are quite frequently
valid reasons for not providing a user override on the choice of 1.0-
or 1.1-based datatypes, but SHOULD at least signals that there CAN BE
such valid reasons.

The upshot is that everyone in the WG can live with SHOULD, but after
vigorous discussion the WG has been unable to find consensus either
for MUST or for MAY here.

We propose, therefore, to close this comment without making any change
to the spec.  Since we do not have consensus that the proposed change
should NOT be made, it seems inappropriate to use the resolution
keyword WONTFIX.  The question raised here remains an important one,
and some (at least) in the WG believe the proposed change should be
adopted, later if not sooner.  Accordingly, we are marking the issue
resolved, with a resolution keyword of LATER.

Francois, as the originator of the issue, may I ask that you review
our decision and its rationale, discuss them with the i18n WG, and
signal either your acceptance of our rationale (by changing the status
of this bug from RESOLVED to CLOSED), or your active dissent from it
(by changing the status from RESOLVED to RE-OPENED, and providing some
new arguments to try to break the logjam within the XML Schema WG).
If we don't hear from you in the course of the next few weeks, we'll
assume that silence implies consent.  (We usually say two weeks, but
since it's August, perhaps four weeks would be safer.)

Thank you.  And (speaking for myself) sorry we were unable to 
generate consensus for the change.
Received on Friday, 17 August 2007 17:18:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:06 UTC