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

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

Matthew Burgess wrote:
> Kasimier Buchcik wrote:
>
> > Matthew Burgess wrote:
> >
> > > 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? :-)
>
>
> Yeah, I knew someone was going to ask that, but I thought my email was 

I was tempting to ask :-)

> getting too long as it was :)  Basically our scenario is this: we have 
> folks send us XML files (generated on their behalf by some GUI) which we 
> then have to validate before processing.  If the file is invalid, we 
> need to give them as much help as possible for them to be able to fix 
> their document before resending it.  They don't know what an XML Schema 
> is nor what any of the schema terminology means.  Now that I think about 
> it, they probably wouldn't even know what XML, 'element' or 'attribute' 
> means either - more on that later!
>
>  > 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.
>
>
> OK, consider the message I gave in my OP:
>
> "Element 'elemA', attribute 'attrB': The value '0' is less than the 
> minimum value allowed ('1')".
>
>  From that, can you not infer what the facet is (minInclusive, although 
> arguably it could be maxInclusive too once implemented) and given the 
> schema, what the particular type is too?  I might just have simplified 
> the test case too much, but by looking at the schema I can obviously see 
>  what type attrB of elemA should be, and therefore can figure out 
> whether a) the schema is incorrect or b) the instance is incorrect.

Yes, but it doesn't follow anymore the format used throughout the
processor.
With the proposed format I still don't have the info which simple type
contains the facet. For anonymous types there would be no gain; but
types are mostly declared globally, so we would get the
name/targetNamespace of the type, which is a really nice information if
you have bigger/multiple-targetNamespace schemata.

Don't get me wrong, I don't want to stick to this format forever, but
for now it's the most consistent, (over-)informative, easy way to
report. For the future I propose to find a way, to pass down the schema
_components_ involved to the error function and restrict the message to
a nice sentence only.

> > 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.
>
>
> OK, I'll admit I am only concerned with the facet stuff for now and 
> therefore am probably blinkered in my opinion at the moment.
>
> Hmm, with more thought, I'm not sure this will actually achieve my 
> desired goal anyway; that is to let the users know, probably even in 
> non-XML terms, why their document isn't going to be processed by us.
>
> Essentially I need the ability to translate what 'xmllint' would tell me 
> into something the users can understand (e.g. "Your document had an 
> invalid 'age' of 'x', it should be between 'y' and 'z'").  They should 
> hopefully then be able to figure out how to change the 'age' using their 
> GUI.

Yes, the error report message is not what you need here.

An idea would be to store an error text template somewhere inside
the <annotation> of each facet; e.g. "Your document had an invalid 'age'
of '%d', it should be between '%d' and '%d'".
A not yet existent error handler would give you the involved facet
component, you read out your template from it and format it with
some provided facet specific error arguments.

xmlSchemaSetValidErrors() does not seem like it could be used to pass
down such information. I think you should ask Daniel, he should see the
big picture, so might know whether this is doable somehow and what needs
to be implemented to get such an error handler.

> Is this what xmlSchemaSetValidErrors() is for?  Does anyone have any 
> examples of their own custom callback functions for this that they could 
> share with me?
>
> > > 1) Implement messages for MINEXCLUSIVE, MAXEXCLUSIVE, TOTALDIGITS, 
> > > FRACTIONDIGITS and WHITESPACE facets (adding testcases of course :))
> >
> >
> > OK, great!
>
>
> The patch for this should be ready in the next couple of days.
>
> > 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.
>
>
> So, can a user get this wrong in their instance, or is this a schema 
> only facet?  From a brief look at the spec, it seems this is very 
> unlikely to be overridden/overridable.

The user cannot get this wrong in his instance.

Regards,

Kasimier