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: Tue, 11 Sep 2007 14:42:28 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1IV6we-0000FI-1I@wiggum.w3.org>


fsasaki@w3.org changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |CLOSED

------- Comment #7 from fsasaki@w3.org  2007-09-11 14:42 -------
(In reply to comment #6)
> 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
> 'conforming'.
> 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.

Hello Michael, all,

We discussed the issue at our call today, see 
We are not happy with your resolution but will accept it.

On behalf of the i18n core WG,

Received on Tuesday, 11 September 2007 14:42:30 UTC

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