Re: [xml] [RFC] More error message changes

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

Matthew Burgess wrote:
> Hi folks,
>
> Would you accept a patch that removed the text in '[...]' from the 
> message below?
>
> test.xml:1: element elemA: Schemas validity error : Element 'elemA', 
> attribute 'attrB' [simple type 'typeC', facet 'minInclusive']: The value 
> '0' is less than the minimum value allowed ('1').
>
> There are a couple of reasons for this:
>
> a) When presented with this, our typical user is unlikely to understand 
> what a 'simple type' or 'facet' are, nor would they be able to change 
> the affected schema even if they did understand it.

Hmm, if they don't understand the meaning of those schema component
names, nor can change the affected schema, why do they read it at
all? :-) This message is supposed to give information to people who
actually can fix the reported errors. When you get XML errors you
would not be satisfied with a "the letters in this thingy between
the brackets are not good", to report a tag's name being not a valid
QName. Additionally thore reports have to be used by both worlds:
by the people who should not read them, and those who need as much
information as possible. The latter being me, since I try to implement
the spec. If you remove that piece of information you remove ability
to implement, to find the error in the instance, and to find the place
in the schema. On the other hand, leaving it as it is, those 'normal
users' can still read the part they understand. See it as a union
for both worlds.
The form of '[xyz]' is used throughout the schema processor, the
piece of the text behind it writen in a manner that the sentence would
become not understandable anymore in many cases, withou a [xyz]; try a
look at all the other reports. Additionally it's mory easy to implement,
since the [xsz] is autogenerated according to the given schema component
and node.

> b) With my previous patch, I believe the text in '[...]' simply 
> duplicates the more human understandable error that follows.

No, really that information is mostly never in the there. Maby it seems
so for facets, but that's only a part of it all.

> However, looking at the code a bit more, I'll admit that information is 
> useful for those facet's that don't have their own specific messages 
> (yet!).
>
> So, if you agree in general with the points above I'd like to do the 
> following:
>
> 1) Implement messages for MINEXCLUSIVE, MAXEXCLUSIVE, TOTALDIGITS, 
> FRACTIONDIGITS and WHITESPACE facets (adding testcases of course :))

OK, great!

The whitespace facet is handled in an other way, it just gives says
how to normalize a value before it is checked against the primitive type
and all the other facets.

> 2) Remove the [...] text from the message

Please don't :-) Or do it, if you implement a parsing + validation
option to turn it on, off. You will end up in writing every report in
two versions to make it understandable.

> 3) Fix the testsuite up so it doesn't expect the [...] text to be output.
>
> Thoughts and comments much appreciated,

I hope this was not too much comment :-)

Greetings,

Kasimier