[dsdl-discuss] Does it make sense to allow <validate/> to borrow the semantics of <unwrap/>?

An important issue about DSDL part 4 has been discussed in in the
thread "[dsdl-discuss] Re: Namespace processing". This mail contains
everything about this discussion.

First, I wrote:

> One comment. <validate> appears to have two roles. One is to create a
> validation candidate and specify a schema. The other is to specify that
> subsequent <attach/> will attach element segments to this validation
> candidate. Meanwhile, <unwrap> specifies that subsequent <attach/> refer to
> an already-established vaidation candidate without creating a new validation
> candidate. Does it make sense to allow <validate/> to borrow the semantics
> of <unwrap/>? For example, <validate schema="xhtml.rng" unwrap="true"/>
> specifies
>
> a new validation candidate be created and validated against the
> the schema xhtml.rng, and
>
> subsequent <attach/> refer to an already-established vaidation candidate
> rather than this newly-created validation candidate.
>
> I hope that this simplifies the example in the section "transparent namespaces".

Then, James wrote:

>
> Interesting suggestion.
>
> One difficulty is attribute sections. It wouldn't be useful if the
> validation candidate validated against xhtml.rng consisted of just the
> element section to which the <validate> action was applied. There needs
> to be the possibility of attribute sections being attached to this
> element section. However, <unwrap/> simply discards attribute sections,
> so I think there's a reasonable solution. If <validate
> schema="xhtml.rng" useMode="x" unwrap="true"/> is applied to an element
> section E, then the attribute sections of E are processed in mode X; the
> results are added to E and validated against xhtml.rng. The child
> sections of E are also processed in mode X and returned as the result of
> the <validate/>.
>
> Another complication is the content model for namespace/anyNamespace.
> NRL is designed so that the order of the children of
> namespace/anyNamespace is not significant. For this reason, at most one
> of the children of namespace/anyNamespace is allowed to be of a kind
> that may have a non-empty result. At the moment, this constraint is
> easy to express: you can have at most one child that is attach or
> unwrap. The constraint would become a little complicated: you can have
> at most one child that is attach or unwrap or validated with unwrap="true".
>
> I don't think it's desirable to have two ways to do unwrap. Either it
> should be a separate element or it should be an attribute (on validate,
> allow and perhaps reject as well). I'm not sure which is better at this
> point.

After a lot of delay, I replied:

>
> I now think that this addition is useful for the combination
> of XHTML2 and XForms.
>
> Consider a fragment as follows.
>
> <table
> <xforms:repeat id="lineset" nodeset="/my:lines/my:line">
> <tr>
> <td>
> <xforms:input ref="my:price">
> <xforms:label>Line Item</xforms:label>
> </xforms:input>
> </td>
> </tr>
> </xforms:repeat>
> </table>
>
> where namespaces are defined by
>
> xmlns:xforms="http://www.w3.org/2002/xforms"
> xmlns="http://www.w3.org/2002/06/xhtml2"
>
> .
>
> This document has five sections: <table>...</table>, <xforms:repeat>,
> <tr>, and <xforms:input ref="my:price">. But we want to create two
> validation candidates
>
> <xforms:repeat id="lineset" nodeset="/my:lines/my:line">
> <xforms:input ref="my:price">
> <xforms:label>Line Item</xforms:label>
> </xforms:input>
> </xforms:repeat>
>
> and
>
> <table>
> <tr>
> <td>
> </td>
> </tr>
> </table>
>
> .
>
> To do so, we want to invoke <attach/> (say attach#1) for <xforms:input
> ref="my:price">. This <attach/> should reference to the validation
> candidate created by <validate> (say validate#1) for <xforms:repeat>.
> We need an <unwrap/> (say unwrap#1) which is invoked by validate#1 and
> invokes attach#1. unwrap#1 is invoked for <tr>.
>
> We also want to invoke <attach/> (say attach#2) for <tr>. This
> <attach/> should reference to the validation candiate created by
> <validate> (say validate#2) for <table>. We need an <unwrap> (say
> unwrap#2) which is invoked by validate#2 and invokes attach#2.
> unwrap#2 is invoked for <xforms:repeat>.
>
> As a result, for each section, we have to invoke actions as below:
>
> <table> validate#2 (invoking unwrap#2)
> <xforms:repeat> validate#1 (invoking unwrap#1)
> and unwrap#2 (invoking attach#2)
> <tr> attach#2 and unwrap#1 (invoking attach#1)
> <xforms:input> attach#1
>
> The first validation candidate has two sections.
>
> <table> validate#2
> <tr> attach#2
>
> The second validation candiate also has two sections.
>
> <xforms:repeat> validate#1
> <xforms:input> attach#1
>
> This is already very complicated. We can go further: <xforms:input>
> contains <p>, which in turn contains some XForms elements, which in
> turn contains HTML2 elements, and so forth.
>
> Then, we need
>
> html validate#2 (invoking unwrap#2)
> xform validate#1 (invoking unwrap#1_1)
> and unwrap#2 (invoking attach#2_1)
> html attach#2_i (invoking unwrap#2_i))
> and unwrap#1_i (invoking attach#1_i)
> xform attach#1_i (invoking unwrap#1_(i+1) )
> and unwrap#2_i (invoking attach#2_(i+1))
>
>
> This can be captured by RNL, but it is too complicated. The reason
> is that <unwrap> has to be specified as an independent action.
>
> If we allow <validate> and <attach> to have the attribute "unwrap",
> we can improve the above invocation sequence as follows.
>
> html validate#2 (invoking validate#2)
> xform validate#1 (invoking validate#2)
> html attach#2_i with unwrap="true" (invoking attach#1_i)
> xform attach#1_i with unwrap="true" (invoking attach#2_(i+1))
>
>
> Use of unwrap="true" for a section S1 implies that <attach/>
> applied to a child (say s2) of S1 reference to the parent of S1.
> Note that, when <attach unwrap="true"/> applies to S2,
> a child of S2 may be attached to S1. That is, unwrap="true"
> controls child sections but does not control non-immediate
> descendant sections.

A correction about this:

> On 3 Oct 2003 14:03:05 +0900
> EB2M-MRT@asahi-net.or.jp (Murata Makoto) wrote:
>
> > Then, we need
> >
> > html validate#2 (invoking unwrap#2)
> > xform validate#1 (invoking unwrap#1_1)
> > and unwrap#2 (invoking attach#2_1)
> > html attach#2_i (invoking unwrap#2_i))
> > and unwrap#1_i (invoking attach#1_i)
> > xform attach#1_i (invoking unwrap#1_(i+1) )
> > and unwrap#2_i (invoking attach#2_(i+1))
> >
> >
> > This can be captured by NRL
>
> No, it cannot. I tried the following schema, but it is incorrect since
> the schema for NRL does not allow more than one <attach> or <unwrap>
> element within a single <namespace> element.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rules startMode="root" xmlns="http://www.thaiopensource.com/validate/nrl">
> <mode name="root">
> <namespace ns="http://www.w3.org/2002/06/xhtml2">
> <validate schema="xhtml2.rng"
> useMode="nested"/>
> </namespace>
> <namespace ns="http://www.w3.org/2002/xforms">
> <validate schema="XForms-Schema.xsd" useMode="nested"/>
> <unwrap useMode="nested"/>
> </namespace>
> </mode>
> <mode name="nested">
> <namespace ns="http://www.w3.org/2002/06/xhtml2">
> <attach/>
> <unwrap/>
> </namespace>
> <namespace ns="http://www.w3.org/2002/xforms">
> <attach/>
> <unwrap/>
> </namespace>
> </mode>
> </rules>

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