W3C home > Mailing lists > Public > public-forms@w3.org > May 2007

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 30 May 2007 15:49:51 -0700
Message-ID: <465DFF8F.2020308@orbeon.com>
To: public-forms@w3.org
CC: www-forms-editor@w3.org

 > 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

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

This really needs to be clarified.


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

Orbeon Forms - Web Forms for the Enterprise Done the Right Way
Received on Thursday, 31 May 2007 00:49:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:51 UTC