Altova Mailing List Archives

Re: Flexible Schemas (was RE: [xml-dev] The task to be solved by RDDL)

From: "Nicolas Lehuen" <nicolas.lehuen@------.--->
To: "Leigh Dodds" <ldodds@-------.--->, <xml-dev@-----.---.--->,"Joe English" <jenglish@---------.--->
Date: 1/19/2002 1:06:00 PM
> > And I'm not talking about exotic, rare and proprietary schemas. To begin
> > with, some examples are all XHTML documents that have modules in other
> > namespaces, like RDDL and WAP 2.0. There are DTDs and schemas for those
> > language, but RDDL is not fit to handle them.
> As I said in my previous message, I don't see this as a problem with RDDL.

As I've said three of four times now, show me the algorithm that will find
the URL of the RDDL document for this document : This
is a FONDAMENTAL problem with RDDL.

> Instead I think it suggests that our approach to writing *schemas* isn't
> flexible enough to deal with documents containing an arbitrary mix of
> namespaces. I should state up front I don't have any answers here,
> I'm just interested in a general discussion.
> The majority of schemas that I've seen assume a fixed set of
> elements. These elements may come from zero, one or more namespaces.
> The schema is "closed". They're designed to validate a particular
> class of documents.
> Some schemas are "open", i.e. they allow "unknown" elements to be
> used in the document, and these usually in fairly fixed places (cf: XSD
> ANY, XHTML DTD Modularization). However these schemas still seem
> to be designed to validate _documents_. They validate the document,
> and ignore sections of it, or as with modularization defer to other
> schema/dtd modules.
> Yet the scenario you're discussing is one which seems like it could
> become increasingly common: we have a mixed namespace document
> for which there is no schema. You're asking, how can I validate
> these documents? Is there a heuristic for combining together several
> schemas to achieve this goal?

In fact there are schemas for RDDL and WAP 2.0, DTD are provided for both
examples. Nothing prevents a schema from manipulating names from different
namespaces. However, the scenario I'm discussing is a scenario where the
document has not a single namespace, breaking the false but too often
believed assumption that a namespace name is equivalent to a DOCTYPE

Regarding "open" schema, that is to say schema that are meant to be extended
or inherited, there is indeed a problem. I think namespaces are part of the
solution, but are in no way THE solution.

> To do this you need to define schemas not only to be open, but also
> to be easily fragmented so that portions of it can be applied. I can
> imagine doing this with a schematron schema (only apply certain
> but not with a DTD. I also assume there's a way to do this with RELAX NG
> and XSD. You then need to apply these fragments to the document to
> validate it.

Yeah, I think that in opened schemas, partial validation of "patterns" are
required, instead of global validation of whole documents. This can be done
with the current schema languages, though, even DTDs. I tried to write down
some thoughts about it there :

> I don't see schemas being written with this use in mind, nor do I see
> validators that allow this flexible application of schemas.
> I may be showing a lack of understanding here, I don't mind
> looking a fool :) Does anyone else see this as an issue, or is it
> not a problem? Am I misunderstanding something?
> RDDL only enters this picture as a way to associate a schema, or
> fragment thereof with a Namespace URL. Doing something with those
> fragments, assuming they're available is something for the validator.

Schemas can be associated to namespace (one or many namespaces), but the
contrary is, IMHO, a bad idea. I am sorry, but I don't see how to solve this
problem without relying on the concept of document or element type. I'll try
to expand on this in the article mentionned above.


> Cheers,
> L.
> --
> Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda
> |    sine necessitate"
>    |     -- William of Ockham


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.