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

Re: modeling, validating and documenting an xml grammar

• To: "xml-dev@l..." <xml-dev@l...>
• Subject: Re: modeling, validating and documenting an xml grammar
• From: Rick Marshall <rjm@z...>
• Date: 19 Jun 2003 13:53:27 +1000
• In-reply-to: <Pine.LNX.4.44L0.0306182035290.809-100000@s...>
• Organization: Zenucom Pty Limited
• References: <Pine.LNX.4.44L0.0306182035290.809-100000@s...>
• Reply-to: rjm@z...

in my experience of these things the worst data quality problems are the
ones that can't be expressed by some dtd or other spec.

the best reason for allowing m,n restrictions is that it reflects the
modern approach to numbers - in the beginning there was 1, 2, many; then
we got 3+; real numbers etc. we now think in terms of more than 1, 2,
many and it seems reasonable to me that we should express that in our
specs and then learn to live with the consequences of our precision. we
will build better systems as a result of this.

however the restrictions won't make the data quality better because of
the simple fact that if i know there should be 1 - 5 entries and there's
6 i know it's wrong, but if there's 4 i have no idea if it's right or
wrong

so in practice i relax the restrictions in the spec and then use domain
knowledge of things that i know are correct - like less than 6, to test
the quality of the data. i can then use some simple stats to get an idea
of the probable error rate in the difficult to test stuff. i lose this
ability when the operators are constrained. worse as pointed out in
another posting, users often enter more rubbish to gtet around the
restrictions thus increasing the error rate further.

rick

On Thu, 2003-06-19 at 10:39, Rich Salz wrote:
> > Even in a case like that, somewhere you or software would have to decide
> > what to do in case there were more records than the form could hold.  That
> > cannot be done with the information in the schema anyway.  So why bother
> > putting the constraint into the schema in the first case?  It doesn't really
> > solve the problem it is there to handle.
> 
> I am in awe of the hubris of folks who can make such generalizations.
> 
> "Trust me, if you try to strictly define your data, then your software
> will [expletive deleted]."
> 
> Wow.
> 
> Perhaps folks really mean "this is the final straw, making XSD so
> complex that as validation-implementors we cannot stand for it."
> But that is not what they've been saying.
> 
>         /r$
> 
> --
> Rich Salz                  Chief Security Architect
> DataPower Technology       http://www.datapower.com
> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
> XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>

• References:
  • Re: modeling, validating and documenting an xml grammar
    • From: Rich Salz <rsalz@d...>

• Prev by Date: RE: modeling, validating and documenting an xml grammar
• Next by Date: RE: modeling, validating and documenting an xml grammar
• Previous by thread: Re: modeling, validating and documenting an xml grammar
• Next by thread: Re: modeling, validating and documenting an xml grammar
• Index(es):
  • Date
  • Thread