[dsdl-discuss] Re: Namespace processing

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

> 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.

I agree that this would be a good approach, if it is enough.

> 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.

Sounds good.

> > 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.

Why is it not validation? Feasible validation is the same as transformation
of the grammar (to add epsilon transitions everywhere) then validating.
It is just applying a different interpretation on the grammar, not infering
anything from the document being validated.
  
> 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.

Aha, I suppose this is really a weakness in Schematron then:--
it has no built-in mechanism for schema composition or playing with namespaces
such as allowing imports or reuse. I had thought that belonged to a lower
layer that DSDL should provide. Maybe namespace aliasing in schemas (i.e the
@as attribute in NameSpace Switchboard) is not a part 4 or part 8 problem then,
but should be an assumed minimum capability of schema languages
(e.g. such as WXS import and RELAXNG import).

So instead of Part 4 supporting "as", it would be more reasonable for
Schematron to add an <include> or <import> statement.

So I guess this would reduce my requirements for Part 4 from Schematron
to just providing ad hoc parameters to validation, e.g. Schematron phases,

<param name="xxx" value="xxx" /> elements are enough for this, and/or,
simpler, specifying a convention that all parameters passed to
a Part 4 processors (e.g. by a Part 1 processor, or command line
argument) should be passed back to any validators.

Cheers
Rick Jelliffe

[1] http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed

--
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)