[dsdl-discuss] Re: Namespace Routing Language

MURATA Makoto wrote:

> First, I love the way concurrent validation, <attach/>, and <unwrap/>
> are combined to provide depth-interleaving and "cover". The attribute
> "cover" in MNS was specified for a parent <validate>, while <attach/>
> (and <unwrap/>) is specified for a child <validate>. I think that this
> change simplifies the formal semantics and implementation significantly.

I am glad you like this, because this is by far the most important
change from my perspective. If we agree on this, then I think we are in
good shape. The rest is detail.

> Second, I am not sure if mode inheritance is required. At least, the
> motivating example in Section 13 is not persuasive: we can get rid of
> the mode "common". I am also confused by the precedence rule (quoted
> below).
>
>
>>1. a non-wildcard rule in x
>>2. a non-wildcard rule in y
>>3. a wildcard rule in x
>>4. a wildcard rule in y

Let me see if I can come up with some more compelling examples, both for
  mode inheritance and the precedence rules.

> Third, I am not sure if namespace wildcards are powerful
> enough. Since we cannot specify <choice> of multiple namespaces,
> I think that schema authors sometimes have to create more than one
> <namespace> having the same content.

I haven't yet found an example where I needed this. Do you have an
example? When you have a schema that covers two or more namespaces (but
not any namespace), don't you typically know what the root namespace is?

> Fourth, I do not like the keyword "attach". How about "super", "parent",
> or "parentSegment"?

I'm not wedded to "attach", but I think the keyword should be a verb for
consistency with all the other actions (validate, reject, allow,
unwrap). In choosing "attach", I started by trying to write a
description for the tutorial and then chose the keyword based on the
fact that I had used this word in the description. It seems my
description is not working for people. I suggest we rethink the
description at the same time as choosing the new keyword. Other
possibilities for the keyword might be: "mount", "merge", "join",
"combine". What's the best way for a user to understand what attach does?

> Fifth, as Rick proposed, some syntax sugar for <attach/> and <unwrap/>
> would be useful. Although I do like the idea of specifying <attach/>
> or <unwrap/> at a child <namespace> (rather than a parent <namespace>),
> I think that such child <namespace>s make NRL schemas longer and less
> readable.

I didn't find the nesting to be an improvement. I haven't yet
appreciated what the syntactic ugliness is that you and Rick feel is in
need of sugaring.

> Sixth, I have some editorial comments. Sections and element sections
> should be clearly defined before they appear in the spec/tutorial.

Section 2 defines sections. I see that there's a forward reference to
attribute sections in section 11, which I've removed. I also see that I
haven't explicitly said that an attribute section is a section
containing attributes and an element section is a section containing
elements, which I should probably say in section 12. Does that deal
with your concern?

> The
> second para of Section 12 should use some special font for the tokens
> "attribute" and "elements".

It's actually marked up as <code>, but, at least on my machine, the
mixture of sans-serif and monospace looks really ugly, so the stylesheet
turns off the font switch. I need to find some non-ugly way to
distinguish <code>. Any suggestions?

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)