[dsdl-discuss] Re: Namespace processing

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

The RELAX Namespace DTR takes 21 pages, and it is too simplistic. If we incorporate
some (not all) mechanisms of MNS and your "Namespace Switchboard" into the current CD
text, I think that it will need 40 pages. If we introduce default values,
architectural forms, and some other rewriting mechanisms, I think the net result
needs 100 pages.

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

Although I think some of the experimental mechanisms of MNS are not
mature enough and should probably be moved to other parts, I do not think
that MS goes a lot further than "Selection of Validation Candidates". In
particular, I do not think that modes deviate from the scope of "selection
of validation candidates". A good use of modes is available at:

http://www.w3.org/People/mimasa/test/schemas/rng/hybrid.mns

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

Here we agree.

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

Although I have not read the source code of Jing, I do not think that MNS
requires a monolithic implementation. When I designed RELAX Namespace,
modularity is my major concern, and my implementation technique is sketched
by "Prototypical implementation of Divide-and-Validate" at:

        http://www.xml.gr.jp/relax/divideAndValidate.html

Two years ago, Kohsuke Kawaguchi has fully implemented this framework. We made
sure that nothing in RELAX Namespace is specific to RELAX Core.

MNS requires significant extensions to my implementation strategy. In particular
modes do require extensions (probably we need a stack of modes). However, I
do no think that MNS requires monolithic implementations.

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

Now, I understand your concern. It would be helpful if you show why MNS
or the Part 4 CD cannot play with Schematron. I think that no mechanisms
in MNS or Part4 CD are closely related with RELAX NG and that they can
play with Schematron very well. I may be mistaken, since my understanding
of Schematron is limited. But I would like to see clear reasons that
MNS does not play with Schematron.

Cheers,

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