Re: Structural schema validation and datatype validation of first text node

 > 1. My longest standing action item right now pertains to a group
 > decision to have revalidate only perform validation of datatypes,
 > not structural validation, *except* during submission.  I have had
 > that on the backburner for a while now due to more pressing issues.
 > The way things look, I could use help getting around to the writing.
 > Hence, what 4.3.5 currently says is that *all* instance nodes are
 > checked for validity.  So I don't understand why you think full
 > structural validation never happens, esp. before submission.

I guess I read the text yet had in mind things we discussed in the
group ;-)

4.3.5 does say:

   "the node satisfies all applicable XML schema definitions (including
    those associated [...] by an external or an inline schema [...])"

Which I take includes complex types.

 > Anyway, the conclusion to this response is that I don't think
 > additional work is needed beyond what is already committed in action
 > items.

I agree.

 > 2. Yes, we did think of alternatives, and at last year's June FtF I
 > believe, we ended up agreeing that the simplest way to ensure that
 > the type MIP was not applied to nodes with complex content was to
 > say they didn't apply to nodes with child elements.  Having a UI
 > binding to the first child text element is a messy hack, by the way.
 > Hmm. perhaps that statement will produce some spirited responses :-)

And there is more. It looks like my understanding of this was
wrong. The current text says in 8.1.1 that:

   "All form controls that read simpleContent instance data must do so
    as follows: [...]  Element nodes: If element child nodes are
    present, then an xforms-binding-exception occurs.  [...]"

So concretely this means you can't bind a control to an element
containing one or more children elements. With the current text, this
won't work, period!

I really thought that we meant that the above was possible, but that
the control would read and write the first child node as a text node,
and that child elements were allowed.

Now if this is not the case, I wonder why we keep talking about the
"first text node" when reading or writing data into elements. It seems
that if you bind a control to an element, you just replace the entire
content after all, assuming you didn't get an
xforms-binding-exception.

If the idea of this wording is to deal with sibling text nodes, this
is not necessary: the XPath 1.0 data model explicitly prevents having
two consecutive text nodes, see [1]:

   "Character data is grouped into text nodes. As much character data
    as possible is grouped into each text node: a text node never has
    an immediately following or preceding sibling that is a text
    node."

This really needs to be clarified.

-Erik

[1] http://www.w3.org/TR/xpath#section-Text-Nodes

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Thursday, 31 May 2007 00:49:11 UTC