[dsdl-discuss] Re: Reformulation of MNS for DSDL Part 4

(Quick answer to keep things moving along.)

From: "MURATA Makoto" <murata@hokkaido.email.ne.jp>

> Q1)
>
> You wrote:
> However, the traversal="halt" attribute causes
> validation to fail as soon as the subject is found.
>
> In my understanding, an implementation is free to begin with
> whichever validation candidate. For example, an implementation
> might begin with an embedded RDF metadata or it
> might begin with an XHTML. Do you intend to ensure that
> an implementation must use the depth-first order?

No, however it may.

If a schema halts, then all other schemas evalutions also terminate
and contribute a validity result of "neutral".

> Q2)
>
> I have some vague understanding of "preprocess", "traversal", and
> "result". However, their interaction is not clear to me. For
> example, does the pair (preprocessor="keep" , traversal="skip")
> make sense?

Yes. Do not prune this branch but don't validate it. I.e. skip it.

> Or, does the traversal attribute make sense only when
> preprocessor="prune"? Is the pair (preprocessor="prune", traversal="enter")
> intended to address my concerns about XForms and XSLT?

Yes.

> I would appreciate it very much if you provide one example for each
> combination.

I'll try to get something done over the weekend.

> Q3)
>
> The semantics of "alias" and "as" is not clear to me. Suppose that an alias of
> http://www.example.com/foo is http://www.example.com/bar. Then,
> does an implementation of "Namespace Switchboard" converts
>
> <a xmlns="http://www.example.com/bar"/>
>
> to
>
> <a xmlns="http://www.example.com/foo"/>
>
> before validation of that candidate?

Yes. (Or the implementation acts as if the former were the latter.)

> It would be great if you provide some examples.

Let us say George Bush takes over DOCBOOK and give it a new namespace.
However, it has the same structure as OASIS DOCBOOK documents.

Now we have a document collection with
 - older DOCBOOK documents with no namespace
 - newer DOCBOOK documents with an OASIS namespace
 - recent DOCBOOK documents which use the Bush namespace

We want to validate, and we have a RELAX NG schema that uses the
OASIS namespace, and then we quickly write a new parallel RELAX NG
schema to perform exclusion exceptions.

In this case, we can use the Bush namespace as the main namespace
and the OASIS and no-namespace as aliases. Then we mark the
old DOCBOOK schema to allow it to apply to the Bush namespace.
This allows upgrades to namespaces.

Currently namespace URL don't change because they cannot: consequently
we have the silly hinting mechanism of xsd:schemaLocation as the only
way to handle versioning and URL changes.

This is not so far fetched: for example, the main Schematron implementations
accept Schematron elements both in a namespace and with no namespace,
a nice feature which is another reason why having an explicity ns element
rather than relying on xmls is quite handy. For those Schematron implementations,
no namespace is an alias of the Schematron namespace.

With ISO Schematron, if I change the namespace from the Academia
Sinica Computing Centre domain to some other place, everything breaks.
That is why I think a mapping mechanism is needed, even as a start.

Another example might be if we wanted to make a simplifed version of
W3C XML Schemas: we just establish a namespace equivalence and our
stripped-down schema then can also validate W3C XML schemas that
conform to the subset.

> What is the relationship between these two attributes and Part 8?

The architectural forms is concerned with mapping elements from
one name to another and filtering them, and establishing equivalence
semantics. The alias attributes does this at the namespace level
only, hence it belongs in the namespace-based processor. We are
declaring an equivalence (of some kind) between two namespaces
not only between individual elements. I don't recall that XAF provides
this functionality.

And as does not apply to documents, notionally, but to schemas.

> Q4)
>
> In my understanding, contexts of MNS are intended to utilize existing closed
> schemas. For example, without changing a closed schema for XHTML, a context
> of MNS can specify a constraint that RDF metaxa can only appear in <meta>.
> Then, we can prohibit RDF metadata in <body>.

No. But I think this is something that schema languages should be able
to accomplish, not the selector. The schema languages says "this X can go
here" while the Part 4 says "how do I deal with namespace Y": I don't
think Part 4 should specify a validation language, if possible.

It would be better, IMHO, to provide a standard parameter on
<swictchboard:schema> elements for RELAX NG which instructs
the parser to only validate in certain contexts. That keeps the separation
very clean.

Allowing <schema> elements to take parameters is also more flexible
because it allows provides a framework to evolve schema languages
semantics without having to change RELAX NG spec or Part 4.
I think we can learn from SAX properties/features that it is a
useful thing to provide. For example, Schematron needs parameters
to select the phase. RELAX NG might use parameters to provide
some kind of mode or context information: for example, one
RELAX NG schema could have a parameter "apply in this
context" and another parallel schema could have a parameter
"don't apply in this context".

So it I am not really saying that RELAX NG mightn't benefit from
contexts and modes, just that context and modes are schema-language
specific (like Schematron phases) and so they Part 4 shouldn't be
tightly coupled to them. Language-specific shims are better done
as parameters.

Perhaps an annex or supplement to the RELAX NG spec or to part 4.

> Although I'm not sure if contexts of MNS hit 80-20, I am wondering
> if "Namespace Switchboard" provides any alternatives. Or, are embedded
> namespaces intended to provide an alternative to modes of MNS?

Embedded namespaces provide a simple scoping mechanism, but they
don't go all the way that context and modes do.

Cheers
Rick Jelliffe

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