This proposal seems interesting but it also fails the rudimentory requirement for internationalisation

I would rather add a new xs:message element inside an xs:annotation element to capture this behaviour

I don't believe the schema itself is the right place to do i18n.  For example, a schema might be developed in a different organisation to the one that wants to port an application to a new language.  

A better approach is to use something like Linux's gettext() method ( http://pwet.fr/man/linux/fonctions_bibliotheques/gettext ).

Therefore it doesn't really matter what language a user directed error message is in as it can be translated to a target language at a different stage.  The text can be practically treated as an opague set of characters that are a key to a lookup table.

(In reply to comment #0)
> A Saxonica client wrote today asking for facilities to specify the error
> message that should be produced when validation against an assertion fails.
> 
> I was able to point him in the direction of Saxon's extension in this area,
> documented here:
> 
> http://www.saxonica.com/documentation/schema-processing/extensions11/saxon.message.html
> 
> The client commented that it would be extremely useful to have this as a
> standard facility in the spec.
> 
> Note that Saxon makes this available on all facets, not only xs:assert. It can
> be very useful, for example, on the xs:pattern facet.

+1 from me for this enhancement.

I wish to know the opinion of WG, the pros & cons of following two approaches, for this need:
a)
<xs:assert test="...">
   <xs:annotation>
     <xs:appinfo>
        <xs:message>
           error message ...
        </xs:message>
     </xs:appinfo>
   </xs:annotation>
</xs:assert>

b) xs:assert test="..." message="..."

The advantage of, the means b) to me looks, that it is more easy to specify & very much less verbose (hence easy for schema authors to specify), than means, a).

The advantage, of a) looks to me, that we can re-use an existing framework, of annotations, for assertions messages.

I have a feeling, to go for solution, b) (the advantage of less-verboseness, of 2nd option looks to me, many folds if we have lot of assertions in the schema).

Regards,
Mukul

I'm inclined to favour putting as an element inside xs:annotation, because (a) processors are already required to accept anything there, so it's a non-disruptive change; (b) the element can have an xml:lang attribute, (c) the message can contain arbitrary markup.

I agree with Michael's Comment #4, but can we call it xs:errorMessage rather than just xs:message as I feel the former is less ambiguous.

(And I don't think we need xs:errorMessage to go inside xs:appinfo. i.e. we have:
   <xs:annotation>
        <xs:errorMessage>
           error message ...
        </xs:errorMessage>
   </xs:annotation>
)

(In reply to comment #4)
> I'm inclined to favour putting as an element inside xs:annotation, because (a)
> processors are already required to accept anything there, so it's a
> non-disruptive change; (b) the element can have an xml:lang attribute, (c) the
> message can contain arbitrary markup.

If we allow arbitrary markup for assertions messages, I think it's good, if we have some guidelines (for example, the spec can say, "the string value of the error message is, the concatenation of all text node descendants -- in document order; of the error markup root node"), on how error messages should be constructed for printing on consoles, or say storing them in string variables, in programming languages, because that's the most common way, error messages are utilized. Or perhaps, we can just say, that utilizing the error markup is, implemented defined.

Regards,
Mukul

(In reply to comment #5)
> I agree with Michael's Comment #4, but can we call it xs:errorMessage rather
> than just xs:message as I feel the former is less ambiguous.
> 
> (And I don't think we need xs:errorMessage to go inside xs:appinfo. i.e. we
> have:
>    <xs:annotation>
>         <xs:errorMessage>
>            error message ...
>         </xs:errorMessage>
>    </xs:annotation>
> )

I think, we would need to have an error message in either <appinfo> or the, <documentation> tag of, <annotation>.

I think, the grammar of <annotation> could make this evident (as shown, below):

<annotation
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (appinfo | documentation)*
</annotation>

The <appinfo> tag, looks a more appropriate place to me, to write the assertions error message.

Regarding, <xs:errorMessage> I think the spec could say:
If implementing an error markup in, annotation of an assertion, there should be only one <xs:errorMessage> element within, 'appinfo' tag of 'annotation'. Any following siblings, of the first xs:errorMessage tag, should be discarded by the XSD 1.1 processors, for the purpose of assertions error message, construction.

These are some quick thoughts, from me. The exact wordings of this subject, could be rephrased by the WG.     


Regards,
Mukul

The WG believes that this topic should be covered in a separate note describing best practices for how to handle this issue.  Liam suggests following the i18n practice of publishing "articles" to recommend best practice.

See http://www.w3.org/International/ for examples.