- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 01 Nov 2007 16:43:03 -0700
- To: "Forms WG (new)" <public-forms@w3.org>
John, > I think it is not lax. That's a shame ;-) > I think it is strict except that type libs are imported in a way > that makes them be applied in a lax way. It very similar to lax in that it has similar recursive processing to lax. It seems that the only difference between what you and Leigh are proposing and lax is in the process of determining whether a type exists or not. You say that if the element or attribute is in a namespace of a schema with top-level element or attribute definitions, then 1) a definition must exist and 2) it needs to be strictly valid. lax just says that only if a definition exists, then it needs to be strictly valid. > If you say lax validation, and you have a schema for a namespace > that contains top-level element or attribute declarations, then > undeclared elements in that namespace will not be flagged as errors > because the mode is lax. Right, as said in XSLT 2.0: "In practice this means that the element or attribute being validated must conform to its declaration if a top-level declaration is available. If no such declaration is available, then the element or attribute is not validated, but its attributes and children are validated, again with lax validation. " > This is not desirable. I am not sure why this is not desirable. That seems to say that lax is not desirable. But lax is supported in XML Schema 1.0 and in XSLT 2.0. Do people really complain that lax doesn't solve an actual problem? Maybe they do, I don't know. It seems likely that there are use cases both ways. For lax, I may have an incomplete schema for a particular namespace, and want the elements that I define to be used for validation, but not the ones I have not yet defined. This is not completely unreasonable I think. > If the schema for a namespace contains top-level element or > attribute declarations, then that structural validation should > apply. So if instance data contains elements in the namespace that > are undeclared by the schema, then a validation error needs to > occur. May occur, if that's what you happen to desire. It really doesn't *need* to occur. > We only want to switch to lax mode when the schema for a namespace > contains no top-level element or attribute definitions since in this > case one is guaranteed to always fail validation, but such a schema > is useful for providing a type lib that declares no structures. Well again, that's a possibility, it's not the only one. I am really not convinced that there is a compelling case for a processing model different for lax at this point (XForms 1.1). lax has the benefit of being fully defined in XML Schema and supported by XSLT 2.0. We can add "strict" in XForms 1.2/2.0, which will cover most other useful use cases. Just for the love of reuse I would choose lax rather than our own processing model if our model doesn't have substantive benefits over lax. Maybe we should get the input of external schema heads out there. Finally, there is the argument from Leigh that existing implementations seem to follow that proposal. How compelling is that evidence for XForms implementations that are actually used and under development? -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Thursday, 1 November 2007 23:43:21 UTC