On Thu, 12 Jun 2003 08:27:24 +0700
James Clark <jjc@jclark.com> wrote:
> 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.
Based on my logical formalism, I have been wondering how I should
implement "depth-interleave" and "cover". I have an algorithm but
it is somewhat ad-hoc. I think that your proposal makes validation
away simpler. Thanks for your contribution.
> > 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?
Consider
<namespace ns="http://relaxng.org/ns/structure/1.0"
xml:base="http://relaxng.org/ns/compatibility/annotations">
<covers ns="1.0"/>
<covers ns="1.1"/>
<covers ns="1.2"/>
<covers ns="1.3"/>
<covers ns="1.4"/>
<covers ns="1.5"/>
</namespace>
in MNS. How do you rewrite this in NRL? Six <namespace> elements
having <attach/>?
> > 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).
The behavior of "attach" reminds me of "super" in Smalltalk-80 or
Java. As for consistency, I prefer nowns to verbs. Incidentally,
Rick opposes to the keyword "validate".
> > 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.
The biggest problem is that schema authors have to think of a mode
name. In fact, this is the biggest problem of modes in general. I
think that we should provide some syntax sugar to ease this burden,
just like RELAX NG allows an <element> to have a subordinate
<element>.
> > 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?
Yes.
-- 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)Received on Thu Jun 12 18:22:48 2003
This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:27 UTC