[dsdl-discuss] Re: Namespace processing

> I think it is useful to see that
>@preprocess is an XML->XML transformation, while @traverse
>is an instruction to the validator.

Your interpretation of Part 4 and MNS appear to be as follows: Part 4 extracts
subtrees in an XML document and further controls the way each validator traverses
subtrees. However, this is entirely different from the underlying processing
model of Part 4 or MNS. Unfortunately, the processing model is not explicitly
stated.

I think that it should be possible to implement Part 4 as a SAX event
dispatcher and that validators of schema languages should merely receive
filtered SAX events. In other words, interworking with this dispatcher
does not need any changes to existing validators. In fact, this is the
way James implemented MNS (I read the source code of Jing) and the way
Kawaguchi-san and I implemented RELAX Namespace.

This approach has two significant advantages: First, existing validators
can be used as is if they use SAX as inputs; Second, Part 4 is
guaranteed to be simple, since event dispatchers can not do complicated
things.

Apparently, neither the Part 4 CD nor the MNS spec are clear about
their processing models. I will make sure that the upcoming FCD for Part 4
clearly present its processing model.

> I wonder whether Part 4 can really be general without some mechanism
> to allow "feasible" validation of upper or middle islands. I see this in three
> use cases:
>
> 1) XSLT generating XHTML. We want to validate the XHTML
> elements. But these may include upper islands as well as branches,
> and the use of <xslt:attribute> for example seems to require that
> grammars can be validated against using a weaker strategy, such
> as the "feasible" validation James put into Jing.

This is not validation but rather type inference for XSLT programs.
There is a paper "Towards static type checking for XSLT", presented in the
2001 ACM Symposium on Document engineering conference.
 
> 2) Any grammar that is written closed (i.e. for convenience) but
> which we want to use anyway, but with our own elements
> substituted. (i.e. a similar case to WXS' substitution groups
> a.k.a. equivalence classes)

I think that Option 5 in my previous mail combined with architectural-form-like
Part 8 provides a solution for this. However, I'm not sure if there
are any real requirements about this.

> 3) Any grammar that is written closed but we want to put in
> some exception data. (I.e., similar to WXS' nilled elements)

Contexts of MNS are intended to address this requirement.

> Alias
> ------
>
> WXS provides complex type extension and restriction, plus <redefine>
> and <import> and <include>. Also it provides equivalence groups.
> All of these are attempts to "reconstruct" uses of parameter entities
> in DTDs. However, the WXS suffixation rule is a database-ism that
> is intrusive and excessive in XML. <redefine> breaks type safety
> in any case; indeed, the lack of a struct 1-1 relation between a
> namespace and schema makes type safety fragile anyway.
>
> So alias attempts to provide a simple way of coping, which would
> be generally useful to any validator.

I am wondering whether aliases belong to the scope of Part 4.
It is possible to convert a RNG schema for namespace A to another
schema for namespace B. I suppose that it is also possible to convert
a Schematron schema for A to a schema for B.

-- 
MURATA Makoto <murata@hokkaido.email.ne.jp>
--
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)