(In reply to comment #0)

> In part 2 of both 1.0 and 1.1, NOTATION type has the following constraint:
> 
> "Schema Component Constraint: enumeration facet value required for NOTATION
> It is an ·error· for NOTATION to be used directly in a schema.  Only datatypes
> that are derived from NOTATION by specifying a value for ·enumeration· can be
> used in a schema."
> 
> But it's not clear what "used directly in a schema" means.

It's always been my understanding that it means that NOTATION can only be the base type of a datatype immediately derived as an enumeration.  That's possibly more restrictive than is really necessary, and it doesn't answer the case of xsi:type--since that's in the instance, not the schema.

This issue appears to be on the boundary between editorial and substantive;
I'm marking it editorial, subject to correction by interested parties.

(In reply to comment #0)

> But it's not clear what "used directly in a schema" means.
> - Used as a base type in a restriction
> - Used as a member type in a union
> - Used as an item type in a list
> - Used as the declared type of an element/attribute
> - Used as xsi:type in an instance
> - Used to validate an element/attribute in an instance
> 
> My guess is that the last one is the ultimate goal. We may also have meant to
> require all but the first 1 (as base type) to avoid the last one from
> happening.

I've looked at Structures some more, and thought about this question some more.  My current opinion is that the last one is the one we wanted to completely prohibit.  I believe that that will automatically prohibit using it as an xsi:type value.  All of the other possibilities leave the schema in a state where it is possible (without avoiding an enumeration)--by xsi:type in the instance or a later-in-the-derivation-chain restriction by enumeration--to be in a position to validate an element or attribute in an instance.  Therefore, I think it would be appropriate to formally require that an un-enumerated NOTATION cannot be the final datatype against which a value can be validated, and also add a Note to the effect that therefore such a datatype cannot be used as an xsi:type value.

If this isn't editorial, it has to be acted on this week.  (If I understand our schedule correctly.)

Would it solve this problem satisfactorily if (a) NOTATION were made
abstract and (b) the text cited in the original description of the
problem were replaced with text pointing out that since NOTATION
is abstract it cannot be used to validate an item in an instance document?

(In reply to comment #4)
> Would it solve this problem satisfactorily if (a) NOTATION were made
> abstract and (b) the text cited in the original description of the
> problem were replaced with text pointing out that since NOTATION
> is abstract it cannot be used to validate an item in an instance document?

I'm not prepared to say whether this would solve the problem, but it's certainly not an editorial change.  Currently simple type definitions do not appear to have an {abstract} property,  Adding a new property could hardly be editorial--and would be a change to Part 1 (Structures).  Pity.

Perhaps the restriction could be expressed in terms like "must be treated as though NOTATION were abstract in the sense of [reference to Structures]".  We've tried to avoid where possible making non-XSD users of Datatypes think too much about the details of Structures, but mayhap we have to here?  At the very least, the concept of abstract datatype could perhaps be the guide for the way the restriction is described.

A wording proposal intended to resolve this issue is on the server at

  http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b4602.html
  (member-only link)

and awaits WG action.  It proposes that "used in a schema" is a misstatement
for "used to validate a literal".

I like the simplicity of the proposal in comment #6.

I find it a little strange to mention information items in this constraint (and put the general rule in parenthesis).

Also when a type is derived from NOTATION by specifying an enumeration, we still need to use NOTATION to validate the literal for the enumeration.

I would recast the rule as

"It is an ·error· for NOTATION to be used directly to validate a literal in Datatype Valid (§4.1.4), unless the literal came from the value attribute of an <enumeration> specified on a type derived by restriction from NOTATION. Only datatypes that are derived from NOTATION by specifying a value for ·enumeration· can be used to validate other literals."

Tried to find a simpler way to say the "unless" part. Suggestions welcome.

(In reply to comment #7)

> I would recast the rule as
> 
> "It is an ·error· for NOTATION to be used directly to validate a literal in
> Datatype Valid (§4.1.4), unless the literal came from the value attribute of an
> <enumeration> specified on a type derived by restriction from NOTATION. Only
> datatypes that are derived from NOTATION by specifying a value for
> ·enumeration· can be used to validate other literals."

I think rather than "<enumeration>" (which is in the XML of a schema-document), you mean "...unless the literal came from the {value} of an enumeration facet of a simple type definition derived by restriction from NOTATION".  Given that, do we need to say something more explicitly defined than "came from"?

> Tried to find a simpler way to say the "unless" part. Suggestions welcome.

Sorry, I don't see a simpler way.  Just thought we ought to stay in the schema realm rather than talking about schema documents.

Points in comment 7 and 8 well taken.  Here is a possible
alternate wording. The status quo reads:

    It is an ·error· for NOTATION to be used directly in a
    schema. Only datatypes that are derived from NOTATION by
    specifying a value for ·enumeration· can be used in a schema.

Change this to read:

    It is (with one exception) an ·error· for NOTATION to be used
    directly to validate a literal as described in Datatype Valid
    (§4.1.4): only datatypes derived from NOTATION by specifying
    a value for ·enumeration· can be used to validate literals.

    The exception is that in the derivation of a new type the
    literals used to enumerate the allowed values may be (and in
    the context of [XSD 1.1 Part 1: Structures] MUST be)
    validated directly against NOTATION; this amounts to
    verifying that the value is a QName and that the QName is the
    name of a NOTATION declared in the current schema.

Hmm.  The proposed solution comes dangerously close to preventing validation using Notation in the context of some non-XSD specification.  If, for example, RelaxNG were to invent its own syntax for refining XSD types, might it not be desirable to allow the same appeal to validation against Notation that is made in XSD structures?

Noah

I think the concern expressed by NM in comment 10 is well placed, but 
the wording in comment 9 does in fact go a little bit out of its way to
avoid saying or implying that types can be derived from NOTATION only
by using XSD.  Am I missing something in the wording, or missing another
possible reading of it? 

Imagine I develop Michael's Schema Language (MSL), and decree that in
MSL you can restrict NOTATION by writing 

  <msl:simple name="equation_notations" restricts="xsd:NOTATION">
    <enum>TeX</enum>
    <enum>tex</enum>
    <enum>LaTeX</enum>
    <enum>MathML</enum>
    <enum vc:maxVersion="0.9">eqn</enum>
  </msl:simple>

and that I require MSL processors to check that the values of
equation_notation are also legal as values of NOTATION (either
at run time, since MSL defines restriction as just the addition of
further constraints, or at compilation time, as an optimization).

Imagine that you now come to me and say "but NOTATION says
you're not allowed to do that!  There's a constraint that says the
only literals that can be validated directly against NOTATION are
the ones used to derive a new type from NOTATION."

And I say "Yes?  What is it that the literals 'TeX', 'tex', etc. are
doing, if not specifying the derivation of 'equation_notations'
from 'xsd:NOTATION'?  The rule in the spec licenses precisely
this case."

It's true that the text mentions XSD as an example of a language
that makes use of this license.  But I don't see a way to read
the proposal as restricting the license to XSD.

What am I missing?

(In reply to comment #11)

> It's true that the text mentions XSD as an example of a language
> that makes use of this license.  But I don't see a way to read
> the proposal as restricting the license to XSD.
> 
> What am I missing?

Nothing I can see.  In fact, I don't read there to be any restrictions on any non-XSD system whatever.  If MSL chooses to adopt an equivalent restriction, using its own definition of validation, by all means.  If MSL wanted to allow direct use of NOTATION, that's also OK.

This restriction is phrased in terms of "validation".  We have no control over what "validation" means for non-XSD systems, and no control over their using a different word for their process that is analogous to XSL validation.  To me it seems foolish to have a restriction in terms of that particular word (and/or its variants) that is intended to apply to non-XSD systems.  Otherwise, in "PSL", I'd simply say something like "for the purpose of dealing with the NOTATION datatype's restriction in [XSD], "validation" means...", filling in the ellipsis with something that always works / is always true / whatever, as appropriate.

Perhaps we should note that this restriction explicitly only applies in XSD systems.

<aside>I don't understand why we even have this restriction for XSD systems.  Can anyone enlighten me?</aside>

Michael Sperberg-McQueen writes:

> I think the concern expressed by NM in comment 10
> is well placed,

Thank you.

> but the wording in comment 9 does
> in fact go a little bit out of its way to avoid
> saying or implying that types can be derived from
> NOTATION only by using XSD.  Am I missing
> something in the wording, or missing another
> possible reading of it?

No, I think I was missing something.  Sometimes I think I'm developing a bit of dyslexia.  Where you wrote:

> The exception is that in the derivation of a new
> type the literals used to enumerate the allowed
> values may be (and in the context of [XSD 1.1 Part
> 1: Structures] MUST be) validated directly against
> NOTATION; this amounts to verifying that the value
> is a QName and that the QName is the name of a
> NOTATION declared in the current schema.

I for some reason read:

> The exception is that in the XSD structures
> derivation of a new type the literals used to
> enumerate the allowed values may be


You would have thought the parenthetical would have saved me from this misinterpretation, but apparently not.  I do think there might be some borderline ambiguity in the first sentence, since the only place we've seen any detail on "derivation of new types" is in structures.  Still, I agree it's both strictly correct and OK in practice as it stands.  At this point, we have more important fish to fry.  Sorry for the confusion.

4602: NOTATION and enumeration.
http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b4602.html

Summary: bug report requests that we clarify our restriction on
NOTATION use.  Discussion in Bugzilla; amendment needed.

MSM's recommendation:

   - Adopt the amendment / proposal in comment 9. The status quo reads:

     It is an ·error· for NOTATION to be used directly in a
     schema. Only datatypes that are derived from NOTATION by
     specifying a value for ·enumeration· can be used in a schema.

Change this to read:

     It is (with one exception) an ·error· for NOTATION to be used
     directly to validate a literal as described in Datatype Valid
     (§4.1.4): only datatypes derived from NOTATION by specifying
     a value for ·enumeration· can be used to validate literals.

     The exception is that in the derivation of a new type the
     literals use to enumerate the allowed values may be (and in
     the context of [XSD 1.1 Part 1: Structures] will be)
     validated directly against NOTATION; this amounts to
     verifying that the value is a QName and that the QName is the
     name of a NOTATION declared in the current schema.

(note change of MUST to "will")

The wording proposal mentioned in comment 14 has now been integrated
(as amended by the WG) into the status-quo document.  Accordingly, I'm
marking this issue RESOLVED / FIXED.

Sandy, as the originator of the issue, I ask you to CLOSE or REOPEN the
issue to indicate that you do or do not regard the resolution of the issue
as satisfactory.  If we don't hear otherwise from you by the end of this
week, the XML Schema WG will assume that you are happy with the
resolution.