Re: Major problem with schema needs immediate attention.

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