RE: Question about XML Schema validation

Hi John and Eric,

I thought it would be a useful exercise to try to summarise in one place
everything that I could find on validation, from the 1.0 and errata
documents:

  <http://www.xforms-wiki.com/bin/view/Main/EventXformsRevalidate>

It would be helpful if anyone who is interested in this could cast their
eyes over it and see if there is anything that should be
added/removed/explained better, etc.

During the course of doing this, one thing jumped out which is that the spec
says events like xforms-readwrite, xforms-enabled and so on, are dispatched
during xforms-revalidate (see section 4.3.5, step 3). However, the MIPs that
correspond to these events are not themselves calculated here, but in
xforms-recalculate, so there is no way that these events can be fired at
this time. (Also, the event is cancellable, which means you'd lose events
like xforms-optional, which have nothing to do with validity.)

Probably another errata candidate? ;)

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of John Boyer
> Sent: 08 June 2005 17:16
> To: Erik Bruchez; www-forms@w3.org
> Subject: RE: Question about XML Schema validation
> 
> 
> Hi Eric,
> 
> Yes, the validity of a node comes from the following channels:
> 
> 1) defined schema related to the node (which also implies the 
> type MIP)
> 2) required
> 3) constraint MIP
> 
> (assuming the node is relevant, of course).
> 
> See Section 4.3.5, the xforms-revalidate event.
> 
> Cheers,
> John Boyer
> 
> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
> Behalf Of Erik Bruchez
> Sent: Wednesday, June 08, 2005 3:09 AM
> To: www-forms@w3.org
> Subject: Re: Question about XML Schema validation
> 
> 
> 
> John Boyer wrote:
>  > Hi Erik,
>  >
>  > The erratum is erroneous, and the working group is 
> actively working  > on it.
>  >
>  > The issue has been thoroughly discussed on our last 
> telecon, and its  > resolution is scheduled for our face to 
> face meeting next week.
>  >
>  > I expect there will be some kind of change in what E29 says.
> 
> Thanks.
> 
> Another question I have regards validity and how it relates 
> to the "required" model item property, if at all.
> 
> It seems that "required" mainly impacts submission (according to
> 6.1.3: "indicates that a non-empty instance data node is 
> required before a submission of instance data can occur"). 
> Plus, a control bound to required node may have some visual feedback.
> 
> So far, so good, except that the section on submission is a little
> fuzzy: "Any selected instance data found to be *invalid* 
> stops submit processing...". Definition of "invalid instance 
> data" is not clear. Does this include checking for 
> "required"? 6.1.3 appears to say so, but then it's not 
> validity, it's being required! However, this suggests that in 
> somebody's mind, "valid" is tied to "required".
> 
> An example:
> 
> If you say that an "instance data node" (BTW "instance data node"
> doesn't have a definition in the spec as far as I can tell) 
> is bound to, say, a type "xs:date", and if it is not 
> required, does the node become valid, or invalid? It seems to 
> me that according to the spec the properties on the node will be:
> 
> o valid: false()
> o required: false() (default)
> 
> Is this the intended result? Should then the UI and controls 
> be in charge of marking the node as "invalid" for the user by 
> combining those two model item properties?
> 
> Intuitively, I would have imagined that "required" would influence
> "valid": if a node would be otherwise invalid as per a bound 
> type, but is actually empty and not required, then it is no 
> longer invalid.
> 
> Am I the only one confused?
> 
> -Erik
> 
> 
> 
> 
>

Received on Thursday, 9 June 2005 10:46:00 UTC