[dsdl-discuss] Re: Namespace Routing Langua

From: Murata Makoto <EB2M-MRT@asahi-net.or.jp>
Date: Fri Oct 03 2003 - 05:03:05 UTC

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

Cheers,

Makoto

--
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 Fri Oct 3 07:03:10 2003

This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:27 UTC