Lists Home |
Date Index |
That's exactly what we learned. We developed using XML Spy, used Spy to
generate instance docs, and then validated the instance docs against the
schemas using production parsers, Xerces and MSXML, as well as
development-time checking, with XML Spy, XSV, and (sometimes) with SQC.
That helped us check that the schemas were internally valid (inasmuch as the
tools could tell us) and that the intended instances didn't run afoul of any
further derivation constraints. Catching violations of unique particle
attribution constraints was a particular item that Spy didn't catch.
We found that even between daily Xerces builds, conformance checking changed
and/or was tightened, so things we thought were legal turned out not to pass
muster in a subsequent check. At the end of the day, the released schema
still must claim conformance to the Schema 1.0 Rec, with the caveat that it
is known to parse correctly under a named version (or versions) of
production validating parsers. I agree that some degree of conformance
leveling would help this story. Merely publishing a list of outstanding
issues for a particular parser release doesn't quite make it.
From: Rick Jelliffe [mailto:firstname.lastname@example.org]
Sent: Wednesday, July 24, 2002 1:12 AM
Subject: Re: [xml-dev] XML IDE: What are the top 3 and why?
From: "Mark Feblowitz" <email@example.com>
> I'm not saying that XML Spy is perfect. There are some things that it just
> punts on. I was merely commenting on its effectiveness as a Schema
Actually, anyone who write an XML Schema is certainly well advised to
also have a schema-validating tool different from the one they are using
for development and maintenance, just for the reason that implementations
regularly differ. For contracts, specify that documents must validate
a schema, and specify at least two validators.
For example, only this week we had a beta-tester report that the version
of Xerces we use in another product does not allow a reference to an
definition to be "fixed" when the attribute definition already says fixed.
problem showed up 561 times in their schema: very confusing.
XML Schemas is just too big. Formalization does not necesarily help
developers track down bugs. It needs to be modularized or trimmed.
Make support for key/uniqueness, nillability, xsi:type and restriction
an extra conformance level, for example.
Good tools to use include
- IBM's Schema Quality Checker
- Topologi Schematron Validator (uses MSXML) http://www.topologi.com/
which are all free.
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