RE: Major problem with schema needs immediate attention.

I agree with Erik's last call comment and his most immediate response 
below saying that the spec has a problem because it does not say enough 
about how to apply the schemas (which I have mutated slightly into the 
conclusion that it does not say which schemas to apply to an instance nor 
how to apply them).

I agree with Leigh (and Noah) that strict vs. lax is more fine grain than 
instance level.  In fact, I pointed this out in the prior email by 
indicating that the XSLT 2 "validation" attribute would be better as a MIP 
because this would map more closely to the design of XSLT 2, which allows 
validation to appear on element and attribute declarations, not just on 
result tree declarations.

I agree with Leigh that it would be better for XForms 1.1 to say something 
more about the method without adding more "knobs and dials".  This is why 
my first email on this pointed out a method we have been using to select 
schema.  It is not an ideal method but could be refined to our needs.

It remains the case that the method I mentioned *does not do* what Erik 
describes. Or, at least, I don't see how it does :-)  It is not a method 
for "one-level lax validation".  It is a method for *selecting* the schema 
that will be applied.  Those that are applied are strict.  So the choice 
of lax or strict is a separate issue.  XSLT 2 "validation" describes how 
to apply *all* of the schema. 

However, let's go back to what Leigh just said:

"Each xf:mode/@schema contributes either a type library or a schema 
definition that applies only to nodes in its targetNamespace."

Leigh, the problem we are having is that the above statement is 
insufficient.  Could you tell me *how* each schema definition is applied 
to nodes in its target namespace?

The easiest example is that if you have a "type library" schema for a 
target namespace, then an instance in that namespace will fail a strict 
validation, preventing submission.  It would be necessary to use lax 
validation for the type lib.  On the other hand, if the schema contains a 
structure definition for the target namespace, then lax validation will 
fail to enforce some of the expected structure rules.

Are you proposing that XForms 1.1 should inspect each schema to determine 
if it is a type lib (e.g. no top-level xs:element), and use something 
other than strict validation in that case? 

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab


"Klotz, Leigh" <> 
Sent by:
10/19/2007 01:50 PM

<>, "Forms WG (new)" <>

RE: Major problem with schema needs immediate attention.

I have no quibbles with trying to do a better job in XForms 1.2, and in 
further alignment with XSLT 2.0 and XPath 2.0.
Such changes can only help us, but they are as you say, most assuredly not 
for XForms 1.1.

But it's not clear to me that this is a major problem that needs immediate 
attention, at least not in terms of making last-minute changes to add new 
knobs to twiddle on xf:model and xf:instance.

If anything is needed, it's verbiage about how the processor decides to 
use lax validation.

1. Each xf:mode/@schema contributes either a type library or a schema 
definition that applies only to nodes in its targetNamespace.
2. Verbiage, if needed, could take the form of a template for an 
<xsd:schema> that expresses the above, given a list of Schemas to import 
or include.

Some XForms processors do just that.  Others (I believe the Novell engine 
was reported to to this at the SAP F2F in Palo Alto), combine the Schemas 
in an additive form not expressible using xsd:import or xsd:include.

And again, lax or strict is not necessarily a decision to be made on the 
document or instance level; as you saw from Noah Mendelsohn's discussion, 
it's possible to do this on a more fine-grained basis. 



-----Original Message-----
From: [] On 
Behalf Of Erik Bruchez
Sent: Friday, October 19, 2007 1:23 PM
To: Forms WG (new)
Subject: Re: Major problem with schema needs immediate attention.


I think (John please correct me if I am wrong) that John and I both
recognize that XForms is in charge of deciding how to apply the

The issue is that the current spec doesn't say how to apply the
schema, and I think that we must say how, otherwise different
implementations will validate differently, right?

Picking a default (i.e. strict, or John's "one-level-lax") resolves
the problem in a way, but not in a very satisfactory way IMO, because
there are use cases for "strict", use cases for "lax", and use cases
for "just skip" - three concepts already present in the Schema 1.0

This is why I find the XSLT 2.0 solution compelling: it does say, and
in very much details, "how" to validate, and it allows the stylesheet
author to better control how schema definitions are applied.


Klotz, Leigh wrote:
 > I don't see the need for any changes.  The XML schema processor doesn't
 > say what interfaces must be provided by the XML schema validation 
 > This issue is assuming that the policy is strict validation and that 
 > presence of even a single type library with no element declarations
 > would invalidate all instances.
 > That's simply not the case; the application itself (in this case,
 > XForms) is in charge of deciding how to apply XML Schema validation.
 > Granted, if you use Xerces in Java and just say "go" it will try to
 > validate everything, but others, (I believe Saxon-SA) won't, and offer
 > more advanced interfaces.
 > But any issues I see here are about using OTS open source software with
 > insufficienct interfaces to implement what's clearly allowed by the XML
 > Schema standard.
 > Take a look at what Noah has to say on this issue:
 >  From
 >     Can schemas validate parts of an instance document?
 > Yes, for example XSV <>, for
 > example, will use "strict" mode if every element from the root down is
 > schema-validatable, but "lax" mode if the root node - or any other
 > element which is allowed to appear in some context - cannot itself be
 > schema-validated.
 > [Noah Mendelsohn] From xmlschema-1
 > <>: "With a schema
 > which satisfies the conditions expressed in Errors in Schema
 > Construction and Structure (7.1) above, the schema-validity of an
 > element information item can be assessed.". It then goes on to say
 > exactly how and against which declarations. Note that it says you can
 > validate an "element", not necessarily the root element of a document.
 > Net answer to your question: conforming processors can be written to
 > validate any element you like. Not all processors need provide this
 > service: buy or use processors that validate the information you need
 > validated. By the way, the detailed rules give the processor a choice 
 > validating the element against some particular identified element
 > declaration, some particular identified complex type, or to use the
 > mechanisms of strict, lax etc. to determine what to validate based on
 > what declarations happen to be available. All of this is explained at
 > xmlschema-1 <>.
 > *From:* [
 > *On Behalf Of *John Boyer
 > *Sent:* Thursday, October 18, 2007 5:51 PM
 > *To:*
 > *Cc:* Forms WG (new);
 > *Subject:* Re: Major problem with schema needs immediate attention.
 > Hi Erik,
 > Regarding validate vs. schema attribute on instance, are you saying 
 > if you have
 > A.xsd: schema targetnamespace="A"
 > B.xsd: schema targetnamespace="B"
 > <instance validation="lax">  <e xmlns="A"/>
 > Then both schema A and B will still apply to the instance but both will
 > be applied with lax validation?
 > This compared to
 > <instance schema="A.xsd"> <e xmlns="A"/>
 > To me, the latter is more compelling.  It directly says what schema are
 > applicable, not how to apply the schema.  It does get even more
 > compelling the more instances (and hence schema) become involved.
 > Frankly, I do actually think there is a also a use for the validation
 > attribute you advocate, which is interesting because it is another
 > datapoint to suggest that the two are separate things.  Still a third
 > point would be that XSLTs validation attribute is designed much more
 > like our type MIP.  It is actually applicable anywhere in the result
 > tree, so putting it on instance may be the *wrong* choice.  I could
 > easily see schema on instance and validation as a MIP.
 > Anyway, regarding 'not invented here' syndrome, I'd have to say the
 > Forms team has done a pretty good job of demonstrating that we don't
 > have the problem.  Proof points would be XPath and XML Schema.  Even
 > though both create a few rough edges for us, they solved many many more
 > problems than they created.  I think the same will be true of things
 > like XSLT2's validation attribute (only that's a much smaller scale).
 >  If we find we need it, it'll get pulled in, but if I had to guess 
 > as I said above, it would probably be as a MIP.
 > That still leaves us with selecting schemas to apply.  To that end, I
 > would say that we should not be so worried about 'not invented here'
 > syndrome that we refuse to adopt new ideas *because* another group
 > didn't think of it first, even when faced with a problem in the same
 > domain.
 > John M. Boyer, Ph.D.
 > STSM: Lotus Forms Architect and Researcher
 > Chair, W3C Forms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail:
 > Blog:
 > *Erik Bruchez <>*
 > Sent by:
 > 10/18/2007 04:08 PM
 > Please respond to
 > To
 >               "Forms WG (new)" <>
 > cc
 > Subject
 >               Re: Major problem with schema needs immediate attention.
 > John & all,
 > Sorry for the over-long reply below.
 >  > Michael Sperberg-McQueen gave a talk at XML 2005 in which he did
 >  > indeed describe the appropriateness of deciding to use different
 >  > schema on the same data for different purposes. It is absolutely
 >  > under the control of the application to decide whether and which
 >  > schema to apply to *any* XML, and it has nothing at all to do with
 >  > having a "pseudo-lax" schema method.  What I believe we are talking
 >  > about is how the application called XForms should decide whether and
 >  > which schema to apply to pieces of XML that it manages.  Once the
 >  > schema are selected, the validation is strict.
 > Agreed, XForms has 100% control over how it decides to apply schema
 > validation.
 > However, a design principle I believe is good consists in leveraging
 > or reuse as much as possible from existing (good) work. This has many
 > benefits, including less time spent devising new solutions to existing
 > problems (the XForms WG really doesn't have the bandwidth to lose time
 > on such things), and consistency across specifications, in this case
 > between XSLT 2.0 and XForms.
 > This is the exact same reason I am very much against us defining new
 > XPath functions to solve problems that already have been solved by
 > XPath 2.0. I really don't want to duplicate the work or, even worse,
 > propose solutions that are not better than existing ones but that are
 > simply different.
 > So yes, we can devise our own way of applying schemas to instance
 > data, but if XSLT 2.0 has done something that can work for us, then I
 > think that we should do a maximum to adopt that. And I believe at the
 > moment that XSLT 2.0 does solve our issues so I am pushing things in
 > that directly.
 > The bottom line: I would like to make sure we are not having a case of
 > "not invented here" syndrome.
 >  > For my own part, I presented the method we currently use to work
 >  > around the problem using a "common sense works pretty well but not
 >  > perfectly" approach that does not happen to require extension
 >  > attributes unsupported by the XForms schema.
 > The reason I used "pseudo-lax" was BTW not to be derogatory, but
 > because the "lax" validation algorithm does what you propose, except
 > it recurses down the XML document to test all the elements and
 > attributes. So your solution is a sort of "one-level lax" validation
 > mode, if you prefer ;-)
 >  > You've proposed that perhaps we should use attributes like those in
 >  > XSLT 2.0.  Based on what I've seen in your last call comment and in
 >  > a brief look at Section 19 of XSLT2, it doesn't look appropriate for
 >  > XForms 1.1.  It seems like the XSLT2 attributes solve a different
 >  > problem.
 > I don't think so, and that's what I have been trying to argue!
 >  > 1) One problem is that XML Schema 1.0 does not mandate that
 >  > implementations provide an execution mode other than strict, and I
 >  > know at least one mainstream schema engine that could support the
 >  > XSLT 2.0 attributes as applied to XForms, which may not even have
 >  > the same semantic as XSLT2 in any case.
 > Are you saying that it would be an issue to have to require tighter
 > integration with the schema validator, like XSLT mandates?
 > If so I can relate to that. For example, at our last f2f, I expressed
 > surprise at the (very late) realization that we cannot simply use a
 > stock XPath validator to implement the depency system!
 > However, my experience is that you can implement lax validation fairly
 > easily with some existing validators, in our case MSV. Lax validation,
 > if not directly supported by your validator, requires that you to
 > obtain from the validator a list of top-level types, and then the
 > capability of validating a sub-tree according to a type when you find
 > a matching element or attribute.
 >  > 2) The validate attribute seems to hit the wrong problem, the
 >  > modality of the schema engine as opposed to the applicability of
 >  > schema to the instance data.  I have long felt that XForms 1.0 has
 >  > the design flaw that the schema attribute is attached to the model
 >  > and not to the instance element.
 >  > I think this may be left over from the good old days when a model
 >  > only had one instance.  If we did go with a solution for XForms 1.1
 >  > that added markup, I would rather see this:
 >  >
 >  > <instance id="X" schema="X.xsd Y.xsd #inline-schema"> ...
 >  > If you don't include a schema attribute on an instance, then I 
think no
 >  > schema should applicable to it.
 >  > The schema attribute on instance would make the selection of 
schema for
 >  > the instance direct and explicit, and it makes processing most 
 > I agree partly with this.
 > However it is intersting to note that XSLT 2.0 actually does things
 > very much the XForms way by allowing you to import a number of schemas
 > into a stylesheet! Then XSLT defines with attributes how those schemas
 > apply to a resulting XML documents. We have a very similar situation
 > in XForms, except our resulting documents are instances. Really, the
 > parallel is striking to me!
 > Given what XSLT 2.0 has done, I now think that importing schemas at
 > the top-level in an XForms model is perfectly acceptable, as long as
 > we add to instances attributes similar to what was done in XSLT.
 > Also note that XSLT allows you to also specify a @type attribute, if
 > you really want to mandate a particular type for a document. This
 > would do the job of selecting which exact schema definition, from the
 > list of imported schemas, must apply to the root element of the
 > instance.
 > In addition, just adding a schema or list of schemas on an instance
 > does seem less powerful than what XSLT 2.0 allows you do to.
 >  > 3) I also didn't like the validation attribute because I didn't feel
 >  > adding it to XForms is not really "futureproof".  We have long felt
 >  > that we need to make the schema engine a pluggable component of
 >  > XForms.  The validation attribute and its values are very XML Schema
 >  > centric, i.e.  they configure the processing model of the XML schema
 >  > engine, so the attribute would be useful and possibly even confusing
 >  > when another schema engine is being used.  By comparison, a schema
 >  > attribute on instance is just a schema selector to indicate which
 >  > schema are applicable to the instance, so it is schema engine
 >  > neutral.
 > This is a good point.
 > I agree we need to make sure we can be as schema-neutral as possible,
 > and at least not close doors. This may be unfortunately, as Leigh
 > suggested during the last call, something we must work on after 1.1
 > though.
 > We now have schemas imported on the xforms:model element. We can't
 > really get rid of this feature easily I think. And we have xsi:type
 > processing taking place.
 > Still, I can see how such attributes could have a defined meaning only
 > with certain schema languages. But even with Relax NG, a @type
 > attribute can have meaning.
 >  > In conclusion, if we could settle on a method a little more like
 >  > what I first proposed, it might help us to provide guidance for
 >  > XForms 1.0 processors today, not just XForms 1.1.
 > I get this point. I don't dislike your solution, and it is simple, but
 > I really dislike the fact that it doesn't seem to match something done
 > in other specs, specifically XSLT 2.0. It is also not just a subset of
 > what XSLT 2.0 does, i.e. if you then decide that lax validation is
 > what you want by default (as we do now in Orbeon Forms), then the
 > outcome may be different from just checking the root element.
 >  > But if a new attribute is required, it seems to be schema and not
 >  > validate that is needed.
 > Given my blah-blah above, at the moment I don't agree with this last
 > statement.
 > -Erik
 > --
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Friday, 19 October 2007 21:29:40 UTC