I respectfully disagree with the suggestion made in this bug report.  If we change the SHOULD to a MUST, then we create a situation in which software may be required to include code that will never be executed, merely to claim conformance.

XML Schema 1.1 is designed for use in a variety of contexts, including some in which the invoking application may itself be statically configured to use XML 1.0.  The proposed change of SHOULD to MUST would require that code to support XML 1.1-style types would have to be included in a processor merely to claim conformance, even in situations where that code would never be executed.  That is an inappropriate and unnecesary barrier to the adoption of XML Schema 1.1.

I believe that the current draft walks the appropriate line, in strongly encouraging but not mandating support for both flavors of type.

Noah

I'm afraid the comment was misunderstood.  The Note in the spec says that implementations MAY provide the heuristic to choose 1.0 or 1.1 based on the input, but then SHOULD provide an override of that heuristic.  If an application is hard-wired for 1.0, then it will not have the heuristic at all, the SHOULD -- which we argue should be a MUST -- becomes non sequitur and will not cause the requirement of any never-executed code.

francois@yergeau.com writes:

> I'm afraid the comment was misunderstood.  
> The Note in the spec says that implementations 
> MAY provide the heuristic to choose 1.0 or 1.1 
> based on the input, but then SHOULD provide an 
> override of that heuristic.  If an application 
> is hard-wired for 1.0, then it will not have the 
> heuristic at all, the SHOULD -- which we argue 
> should be a MUST -- becomes non sequitur and will
> not cause the requirement of any never-executed code.

Oops. I should have checked more carefully.  Still, in spite of that misunderstanding, I think the spirit of my original comment applies.  If the invoking application is known always to want the heuristic applied, then what business of ours is it to insist on an API that will never be used?  I do agree that in practice, the amount of code involved in adding such an unused API switch will be lower than adding a whole new type system, but it's still a complexity about which I think the schema spec should say little if anything.  

I have always believed that our main purpose in Parts 1 and 2 should be to define the language and its interpretation, and not the packaging of or interface to processors.  I do think it makes sense in principle to >separately< document processor APIs and packagings that are likely to be of common use.  Still, I generally expect to see programming languages documented separately from the APIs, command line switches, or debug options of their compilers.  I think similar considerations apply here.

Noah

(In reply to comment #3)
> francois@yergeau.com writes:
> 
> > I'm afraid the comment was misunderstood.  
> > The Note in the spec says that implementations 
> > MAY provide the heuristic to choose 1.0 or 1.1 
> > based on the input, but then SHOULD provide an 
> > override of that heuristic.  If an application 
> > is hard-wired for 1.0, then it will not have the 
> > heuristic at all, the SHOULD -- which we argue 
> > should be a MUST -- becomes non sequitur and will
> > not cause the requirement of any never-executed code.
> 
> Oops. I should have checked more carefully.  Still, in spite of that
> misunderstanding, I think the spirit of my original comment applies.  If the
> invoking application is known always to want the heuristic applied, then what
> business of ours is it to insist on an API that will never be used?  I do agree
> that in practice, the amount of code involved in adding such an unused API
> switch will be lower than adding a whole new type system, but it's still a
> complexity about which I think the schema spec should say little if anything.  
> 
> I have always believed that our main purpose in Parts 1 and 2 should be to
> define the language and its interpretation, and not the packaging of or
> interface to processors.  I do think it makes sense in principle to
> >separately< document processor APIs and packagings that are likely to be of
> common use.  Still, I generally expect to see programming languages documented
> separately from the APIs, command line switches, or debug options of their
> compilers.  I think similar considerations apply here.

This sounds like you are questioning the usefulness of the note in this section at all?
Felix

Felix Sasaki writes:

> This sounds like you are questioning the usefulness 
> of the note in this section at all?

That's very astute of you.  I think it's fair to say that this note is a bit of a compromise between those of us who think that Part  1  of the Recommendation should be detailed in its guidance on processor implementation, and those of us who prefer that the declarative specification of the legal inputs and corresponding PSVIs of our language should be mostly separate from guidance on processor packaging and implementation.

For the record, I'm reasonably comfortable with the compromise and am not asking to change it, but you are correct to infer that the rationale I've given for my position would push a bit in the direction of saying somewhat less.  Then again, this is a note, and I'm mostly OK saying in notes things that I don't think otherwise belong in the document.

Thank you!

Noah 

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.

(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 
http://www.w3.org/2007/09/11-core-minutes#item04
We are not happy with your resolution but will accept it.

On behalf of the i18n core WG,

Felix