[dsdl-discuss] Re: Namespace processing

From: "MURATA Makoto" <murata@hokkaido.email.ne.jp>
 
> To me, this looks like an attempt to merge Part 4 and Part 8. I am wondering
> why these two parts 2 should be merged, since the merged spec is likely to need
> more than 100 pages.

Where do you get the number 100 from? I thought we were being a little flexible
on what belongs in parts 1, 2 etc in any case. For example, MNS goes a
lot further than "Selection of Validation Candidates" and is actually
just as much about "Selection of Schemas" (e.g. modes). (The WG will need
to do some rectification of names of parts.)

> Are there any requirements which cannot be satisfied by
> Part 4 and Part 8? Concrete examples are appreciated.

My original understanding or DSDL was the each part would map to a separately
implementable filter, and that these filters could be chained together.
This was the XML-in, XML-out, anti-PSVI, schemamachine approach.

But (am I mistaken here?) it seems that James' MNS requires a monolithic
implementation as part of, in particular, RELAX NG. So it looks modular without
actually being any more modular than W3C is, for implementers.
Is having a pre-schema validation infoset (i.e. a view) really that much
different from having a PSVI, from an implementation complexity POV?

This seems a very basic architectural decision that I think must be made
explicit. I have no objection to the idea that we work off views rather
than the original XML, because it fits in well with XSLT nodesets.

But almost none of MNS is applicable to Schematron, so I think it
is a worthwhile question to ask if there is some other way to reformulate
it (in particular, using XPaths) which may make it more general.

I don't think this is framework-itus, or ISO disease (trying to find the most
general case, and exploding because of it), because DSDL *is* supposed
to be a framework for supporting different schema languages.

Now, I understand that there are advantages in having one part for
RELAX NG and another part for everything else we need to make
RELAX NG competitive with WXS. I have no objection to Part 4
being entirely RELAX NG specific, and renaming it accordingly
"Language for configuring RELAX NG processors" or whatever.

But I don't want to waste my (or your!) time (with Schemamachine and the
switchboard idea) working through Part 4 issues if ultimately it is just
applicable for RELAX NG. If it is meant to be general, then it
should be general (which I think the namespace switchboard and
the XPath-based idea, or formalizing the views that validators see, are);
but if it is targetted at setting the stage for RELAX NG, that is fine too.
As long as we know what the real requirement is.

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)