[dsdl-discuss] Re: Namespace Routing Language

On Thu, 12 Jun 2003 08:44:44 +0700
James Clark <jjc@jclark.com> wrote:

> What should I say about the relationship between Part 4 and NRL in the
> NRL tutorial/spec?

First, although we are the participants of SC34/WG1, we are not
SC34. Prior to the next SC34 meeting, we cannot make SC34 change its
agreements or reach new agreements. We can only execute existing
agreements.

Second, now that RNL will appear soon, I do not think that we should
create the FCD in a hurry. It should be created in the next meeting
in December. SC34 does not have any problems about this delay.

Third, what can we say about the relationship between RNL and the Part
4 FCD? Let us study which feature of RNL can be considered as status
quo.

1) Agreed mechanisms

SC34 has agreed on the comment disposition document N415. If a
mechanism of RNL follows the instructions in N415, we can ensure that
this mechanism will be adopted in the FCD. The concrete syntax may
change, but we can ensure safe migration.

In some cases, N415 is intentionally ambiguous and explicitly allows
the project editor to innovate, and I would like to "innovate" by
adopting mechanisms of RNL. Then, we can again ensure that these
mechanisms will be adopted in the FCD.

I think that the following mechanisms of RNL belong to this category.

- element and attribute sections (which are arguably editorial)
- modes
- concurrent valdation (Although N415 is silent about this, SC34 has never
                        agreed that a rule has one action.)
- namespace wildcards
- allow and reject
- attach
- the attribute "match"

2) New features

Some mechanisms of RNL are entirely new and have not been discussed by
SC 34. I think that these mechanisms should be explicitly marked as
such. In other words, safe migration is not guaranteed.

- mode inheritance
  (Note: I am personally skeptical),

- options and arguments
  (Note: I personally do not oppose),

- use of the media type application/x-rnc (RFC 2046 says "publicly
  specified values shall never begin with X-").

- error information as a result of validation
  (Note: I personally do not oppose)

3) Omitted features

RNL does not provide some of the mechanims agreed in N415. I think
that some notes about these features in the RNL spec would be
helpful.

- inline schemas

- schema inclusion

- The "ELEMENT ROOT" option

Note: SC34 agreed to DROP the option "dummy". However, another option,
which keeps the ROOT of element sections, was agreed on. I think that
this mechanism is useful and free from the problems of "dummy".

4) Discussed but not-agreed features

- unwrap

N415 says:
>However, we agreed not to introduce the option "depth-interleaved" for
>now, but add a note about this option. Although the option
>"depth-interleaved" is interesting, no schemas use it and no
>implementations support it as of now.

- element-name contexts

N415 says:
> 7) Do not introduce contexts for now.
> Reject. Contexts are useful for handling closed schemas. However, add a note about
concerns as follows:
> too complicated and outside the scope of Part 4 [ISUG],
> too weak to reuse closed schemas as is [JAPAN],

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)