[dsdl-discuss] Re: Namespace Routing Language

MURATA Makoto wrote:

> I think that some paragraphs about the relationship between NRL and the Part 4 FCD
> are strongly required. In particular, is NRL technically identical to the
> Part 4 FCD (which does not exist yet).
>
> It would be very nice if we agree to adopt RNL as the FCD and James can
> say so in this RNL spec. James, please postpone public announcement of NRL
> until next week? I will read NRL carefully and post my opinion to this ML
> in a few days.

I will wait.

I wouldn't expect for us to adopt NRL unchanged for the FCD. I am sure
WG members will have areas where they see potential for improvement.
What I would like to see is that we use NRL as the starting point, on
the basis that it is the most fully worked out proposal (tutorial,
formal semantics, implementation supporting multi schema languages) and
then proceed by considering proposals for how to change NRL. Also it
would be useful to be able to say that Part 4 will provide at least the
functionality of NRL though perhaps with different syntax and perhaps
excluding particular functionality (and I could ask for feedback from
users on utility of functionality that we haven't yet got consensus on.)
  This would allow people to start taking advantage of the functionality
and be confident that there will be a migration path to something
standard. I'll be glad to add some paragraphs to the NRL doc explaining
the relationship to the FCD once we decide what it is (but I don't want
to make any assumptions about what the SC34 is going to decide before it
has actually done so).

I think NRL has all the functionality that has been mooted for Part 4
with the following three exceptions:

- Inline schemas. It's obvious that this is useful and it is obvious
how to add it (allow a schema subelement as an alternative to a schema
attribute on validate). The problem is implementation. Specifically,
the problem occurs in reporting line numbers for errors in the schema
when you are using a 3rd party schema implementation. Typically, schema
implementations not designed specifically for use with this type of
language cannot start reading the schema from a subelement; they expect
the schema to be a complete XML document. You can serialize the inline
schema, but then the line numbers bear no relation to the real line numbers.

- Schema inclusion. I haven't thought this through yet. I'm not clear
how it relates to using NRL as a subschema. I think this will depend on
how overriding works. Also I have a general concern about how schema
inclusion will work for DSDL as a whole. Consider XHTML M12N which has
over a dozen modules. When you just have RELAX NG, things are easy. You
make your particular dialect, just by including the appropriate modules
in the top-level RNG driver. But suppose each module needs to use
multiple languages (maybe a bit in RNG, a bit in schematron and a bit in
a path-based integrity constraint language). Do we give each DSDL
language an include mechanism and then force the user combine the
modules separately for each language? This seems very clumsy.

- No dummy elements. NRL cannot replace an element section by a dummy
element. I think this is only really useful in conjunction with DTDs as
a subschema language. However, I have one major concern about this and
that is error messages. With dummy elements, users may get error
messages (e.g. saw element "dummy" but expected "foo" or "bar" or "baz")
that are incomprehensible unless users understand the internal workings
of NRL, which shouldn't be necessary for merely using a validator.

My main goal with NRL is to produce something that gets people to start
using the kind of functionality that Part 4 will provide. So far I have
been disappointed with the level of interest in the XML community in MNS
and Part 4 generally. In NRL, I have tried to make improvements in a
number of areas:

- Documentation. The NRL doc is hopefully much more accessible to a
potential user than the MNS doc was.

- Less RELAX NG specific. I have added <option> so that the
capabilities of other schema languages can be fully supported in an
extensible way. I have added a richer model of invalidity (a collection
of error information rather than a single bit) to accomodate other
schema languages.

- Implementation support for multiple languages. One of the main
selling points of this approach is that it supports multiple schema
languages, but Jing only included support for RELAX NG. In the upcoming
release, I provide support for Schematron and W3C XML Schema.

- Richer functionality. The support for "transparent" namespaces
provided by "unwrap" (what Rick called "delve") provides functionality
that isn't available anywhere else. The concurrent validation
capabilities have been generalized.

- Marketing. When annoucing NRL, I am going to try to articulate more
clearly the specific benefits that NRL (and in the future DSDL Part 4)
can provide when used in conjunction with particular schema languages.
At the moment, my summary is:

+ Supports schema language coexistence.
+ Allows extension of schemas not designed to be extended
+ Makes authoring of extensible schemas easier; extensibility can be
specified separely using NRL without having to clutter up the main
schema with wildcards
+ Supports transparent namespaces
+ Allows contextual control of extension
+ Allows concurrent validation using multiple schemas
+ For RELAX NG, it provides some of the namespace-based modularity
features that are built-in to XSD

James

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