[xmlschemata] Innie or Outie?

In Australia there is a schoolyard ontology of bellybuttons being =
"innies" or "outies".

Schema languages seem to be the same. Schemachine is an outie and=20
XVIF is (in Eric's trial implementation in RELAX NG) an innie :-)

From: "Eric van der Vlist" <vdv@dyomedea.com>

> Even though their current syntaxes are different, I am confident that
> the semantic of the 3 elements composing xvif is generic enough to be
> used as building blocks surrounded by Schemachine bells and whistles =
:-)

On a logical level yes. But on an implementation level there are three
very distinct levels:
  1) Outside invoking someone's third party schema library
  2) What goes on inside a third party schema libary (and what
   provision they made for extensions)
  3) What can be extracted and embedded by a third-party library.

Figuring out how best to support this distinction is critical, because
we don't want to make XXXX something where an implementer
of a schema language component needs to understand the XXXX
framework.=20

In Schemachine, I decided to treat these three levels using different
mechanisms each.=20
  1) The outside level is handled by the framework, with some
 limited transformations available, such as treatment of validation
 results, stripping items, and wrapping results.
  2) The only ways of the framework interacting with the=20
 library are through parameters or in-band in the document.
  3) Embedded schemas are handled by particular validators
  that understand the format, just as any other extension.

I think a lot of this comes down to our expections of how things will
pan out. I expect that a XXXX user will=20

 * prefer to use grammar-based constraints on structure
  ahead of Schematron initially

 * prefer to use datatyping embeded in the structure language more
  than free floating or Schematron constraints or DTD datatyping

 * prefer to use a declarative mechanism for keys and uniqueness,
   controlled vocabulary and link checking, rather than Schematron

 * use Schematron to fill in the gaps.

 * over time, as maintenance is required, make their grammars
  looser and migrate specific small-grained constraint checks
  to Schematron.=20

  * use a phase/stage mechanism (i.e. reify a bundle of switches)=20
  at the top level and within any schema components that support it
  by parameters (e.g. Schematron) for selecting versions over=20
  time, for progressive validation, and for black-box validation at
  various stages of an augmenting pipeline.=20

So it seems to me that the essential difference is that XVIF seems
to lead to intricately decorated schemas, adn therefore difficult to
reason about and therefore tool-requiring schemas. But I would=20
expect Schemamachine to grow by the grammar-based schemas=20
becoming progressively looser as more constraints are moved to=20
Schematron, or by fairly large chunks of schema being changed. =20

I think the weakness for my approach is that it does not tie into XSD's
<import><include><redefine> mechanism or the inclusions in
RELAX NG or DTDs. I guess the way it would have to do it
to specify as a parameter on validation engines a URL remapping,
so that the particular schemas that are included during schema
construction would be dependent on the phase mechanism. =20

Leigh Dodds has a nice weblog entry on this for people who want to get =
up-to-speed,=20
at http://weblogs.userland.com/eclectic/ for June 20, 2002.=20

Cheers
Rick Jelliffe
Received on Sat Jun 22 10:59:51 2002