[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Required Field validation strategies

  • From: "Michael Kay" <mike@s...>
  • To: "'J Siatkowski'" <jason.siatkowski@g...>,<xml-dev@l...>
  • Date: Tue, 20 Mar 2007 20:01:24 -0000

RE:  Required Field validation strategies
> 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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.