[dsdl-comment] Re: Monolithic schemas are bad, right?

>
> Hi Folks,
>
> In James Clark's NRL tutorial[1] he writes about creating a schema for
> XHTML that imports SVG:
>
> "Suppose we have RELAX NG schemas for XHTML and for SVG. We could use
> these directly as subschemas in NRL. But we might prefer instead to use
> RELAX NG mechanisms to combine these into a single RELAX NG schema.
> This would allow us conveniently to allow SVG elements only to occur in
> places where XHTML block and inline elements are allowed and to
> disallow them in places that make no sense (for example, as children of
> a 'ul' element)."
>
> Later he refers to this as the "xhtml+svg.rng" schema.
>
> I interpret James' paragraph as, "Rather than taking the existing
> schemas and assembling them, create a monolithic schema."
>
> This seems counter to the NVDL philosophy of "taking what schemas exist
> and assemble them."
>
> Most likely I am misunderstanding what James is saying.
>
> Would someone clarify this please?

I think you are reading too much in, but that is your dialog method... :-)

There is nothing in DSDL that says anything about best practices for
creating schemas. It is regarded as entirely orthogonal to the issue at
hand, which is specifying a well-layered set of small individual schema
languages that can be combined to have much more power and simpler
implementation than a monolithic schema language, namely XSD.

The key phrase in James' material that you quote above is "We could..."
"But we might prefer instead to..." In other words, he is covering
common cases.

This is because we don't want to have nice little languages and then in
effect make a big monolith by requiring a particular validation flow. That
would ruin the intent.

Now this is not to say that the idea that it is best practice for schemas
should be non-monolithic is not one that would not have substantial
sympathy in among DSDL-ers, I would think. But I think most of us would
also respect the idea that sometimes a single big schema where the cake is
not layered and allows only one way of cutting it, is indeed workable and
useful. For example, many users have tooling concerns that override other
issues.

I think that flexibility is a big difference between SC34 WG1 and W3C XSD
WG: W3C XSD WG made the decision to go in the direction of extreme
modularity (in the name of validity always meaning validity; no subsets)
which has been their strength and downfall. SC34 WG1 went in the direction
of saying that for meaning validation especially of any "complex"
constraints, you need to have the schemas and schema dipatching follow the
particular requirements of the schemas and the schema languages being
used.

For example, XSD has this enormous problem that when the maintainers of a
schema language did not cope with some kind of openness or extra
constraint that a new user has, that user has to create their own
non-standard schema. NVDL (and DSRL) take the opposite approach, and say
"We want to *allow* the use the texts of the standards schemas unchanged
and make combination a higher level problem."

I think NVRL and DSRL should be built into standards, even for people
using XSD, which is why we need Ant tasks and so on for them. I imagine
these will be coming online this year.

Cheers
Rick Jelliffe

--
DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
(mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)