RE: [xml-dev] Required Field validation strategies

["Michael Kay" <mike@saxonica.com>]

> The other issue, which I didn't discuss earlier because it 
> might have been moot based on the first issue, is my handling 
> of null fields. My schema does indeed have custom data types, 
> i.e. string0to14, etc. It also has some enumeration types. 
> The schema also enforces required fields, although I have 
> been sorely tempted to remove this from the schema because I 
> have not been able to successfully validate a file with nulls 
> without adding xs:nil = "true" to the elements which I want 
> to be null. Only a small amount of the fields are required, 
> and therefore the size of the uploaded file could be a lot 
> smaller if the customer wasn't required to include the tags 
> for elements which have no value. 

There are quite a few views on how absent data should be handled. In my
view, the best way is to omit the whole element (tags and all), which means
the content model in the schema must make the element optional
(minOccurs="0"). I've never seen any point in making elements mandatory but
nillable (that is, allowing the instance to say <data xsi:nil="true"/> -
that seems to me to be an unnecessary intrusion of the relational way of
thinking onto a very different data model. Another option is to define a
default value in the schema, but my own instinct is to handle defaults in
the application - usually because the absence of a value doesn't mean "use
the default", it often means "use the existing value" - for example if
there's no phone number for a customer it means use the one you've already
got on file. (Apart from anything else, defaults for elements don't apply if
the element is omitted, they only apply if it is empty: that is, if the tags
are there but with no value between them.)

One significant challenge is when you are designing schemas for a family of
messages (for example, create, update, and delete messages) and fields are
mandatory in some messages but optional in others. I have seen people make
the data mandatory in all messages simply so they can reuse the same schema
components. That seems to me the wrong approach: you can achieve reuse by
subtyping or by schema generation from some master definition of the message
formats. That bit starts to get quite difficult.


> In my tests, if I omitted 
> the tag, the schema validation failed because the tags were 
> out of order. 

Well, you did something wrong, and we can't tell what because we don't know
what you did. Defining elements as optional is certainly possible.

Michael Kay
http://www.saxonica.com/