RE: Major problem with schema needs immediate attention.

Hi Leigh,

I don't see a reason to special case no namespace and agree with Erik that 
people have been using instances with no namespace to ease their typing, 
and they do use both type libs and actual no-namespace schema on them.

Agree they do also use instances for temp variables, but this would fall 
under Erik's extension proposal to someday have <instance 
validation="skip"> available, which sounds like 1.2/2.0.

Would you be able to massage this idea into something that could be popped 
into the spec, and of course say where?

 :-) 
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: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: public-forms-request@w3.org
10/31/2007 01:38 PM

To
<ebruchez@orbeon.com>, "Forms WG (new)" <public-forms@w3.org>
cc

Subject
RE: Major problem with schema needs immediate attention.







Erik,
Yes, looks good.  The question is how to decide between lax and strict. 
XSLT 2.0 gives the author control, but XForms 1.1 does not.
My proposal is to use the presence of element and attribute definitions 
(structure) as the choice as I believe this is what XForms 1.0 processors 
already do. XSLT lax validation looks like what we want for cases where 
the schema for the namespace has no elements or attributes, and strict for 
when it has at least one. 

Having fine-grained author control as XSLT does would be great, but I 
think we should hold off on importing partial features from XSLT 2.0 and 
XPath 2.0 into XForms 1.1 and intead hold off for 1.2/2.0 when we can move 
to XSLT 2.0 and produce a much better alignment.   Many implementations 
are moving to XPath 2.0 without WG direction, so we'd better get on it.

I am OK with not special-casing the no-namespace if nobody else sees a 
reason we might have to.

Leigh.

-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On 
Behalf Of Erik Bruchez
Sent: Wednesday, October 31, 2007 1:26 PM
To: Forms WG (new)
Subject: Re: Major problem with schema needs immediate attention.


Ok, following-up on this:

Leigh, could you have a quick look at this section in XSLT 2.0:

   http://www.w3.org/TR/xslt20/#validating-using-validation-attribute

Especially the bullet point starting with "The value lax...". Would
this match what you had in mind below?

If so, this would be great. We could then simply say that we validate
instances in lax mode, period (or we could put an explanation similar
to that in XSLT 2.0). We would be following a common validation
pattern instead of inventing our own. And then in the future, we can
add attributes to force "strict" or "skip" or even a particular type,
like XSLT 2.0 does, if we think that this is a good idea.

I don't think we should have a special treatment for nodes that are in
no namespace. Many users put their instances in one or more
namespaces, but many put it in the null namespace. I would expect
validation to work the same whether I am in a namespace or not, and
this approach seems to be fully supported by XML Schema and XSLT 2.0.

-Erik

Klotz, Leigh wrote:
 > Just cutting to the chase here:
 >>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?
 > Yes. That appears to be what existing implementations do and if our 
goal
 > with 1.1 is to fix these inconsistencies then we can do it with what I
 > believe are the two rules that are being used:
 >
 > 1. If there are no elements in the Schema for a namespace, then it
 > cannot be used for structural validation and *should not try*.
 > 2. If there are elements defined in the schema, then it is presumed to
 > define them all (the one schema file per namespace rule).
 > These two rules seem sufficient to me and are allowed by case two of
 > http://www.w3.org/TR/xmlschema-1/#validation_outcome and correspond to
 > the fine-grained schema checking that I believe we are talking about.
 > The question of whether when you have a Schema for a namespace and
 > encounter elements in that namespace that are not in the schema is the
 > strict/lax one, and the Schema people say it's up to the application to
 > say this as well, but since we have the one-schema-per-namespace rule,
 > we can defensibly say that we do not allow lax processing so that 
should
 > be invalid.
 > I suppose a reasonable person might say that we allow schemas for the 
""
 > namespace so we should allow lax processing there, and if you want that
 > I won't disagree:
 > 2.5 If you encounter an element in the "" namespace and the element is
 > not mentioned in any schema for that namespace, you cannot prove it 
invalid.
 >
 > Test cases (note these are not additional rules but tests of the 
above):
 > If you encounter an element in a namespace, if you have a schema with
 > that target namespace and it defines elements, then you can validate
 > that element.
 > If you encounter an element in a namespace, if you have a schema with
 > that target namespace and does not defines elements, then you cannot
 > validate that element (except via bind/@type <mailto:bind/@type> or
 > xsi:type but that's a separate issue).
 > if you have no schema for that namespace, then you cannot validate it
 > (though you may be able to validate its insides recursively, or do
 > bind/@type <mailto:bind/@type> validation but that's a separate 
matter),
 > so it's not invalid.
 > If the root element XYZ in the instance is in a namespace and you have 
a
 > schema for that namespace, then either you can validate every child by
 > that schema, or it's invalid.
 > If you had wanted lax processing of child elements of an element (even
 > if said element is our root XYZ) you should have specified such in your
 > schema, which you wrote.
 > If you had wanted elements in some other namespace to appear as child
 > elements of said element, even if you went to the trouble to mention a
 > schema for that other namespace in the model/@schema
 > <mailto:model/@schema> attribute, you still won't get validity because
 > the schema defining the XYZ element doesn't allow it.
 >
 > If our goal is to give more control to authors about strict vs lax then
 > we need to re-vamp things for 1.2, though I hope we do it in a way that
 > deals with multiple Schema languages.
 >
 > Leigh.
 > 
------------------------------------------------------------------------
 > *From:* John Boyer [mailto:boyerj@ca.ibm.com]
 > *Sent:* Friday, October 19, 2007 2:29 PM
 > *To:* Klotz, Leigh
 > *Cc:* ebruchez@orbeon.com; Forms WG (new); public-forms-request@w3.org
 > *Subject:* 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?
 >
 > Cheers,
 > 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: boyerj@ca.ibm.com
 >
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >
 >
 >
 >
 > *"Klotz, Leigh" <Leigh.Klotz@xerox.com>*
 > Sent by: public-forms-request@w3.org
 >
 > 10/19/2007 01:50 PM
 >
 > 
 > To
 >               <ebruchez@orbeon.com>, "Forms WG (new)" 
<public-forms@w3.org>
 > cc
 > 
 > Subject
 >               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.
 >
 > Leigh.
 >
 >
 >
 > -----Original Message-----
 > From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
 > 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.
 >
 >
 > Leigh,
 >
 > 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
 > schema.
 >
 > 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
 > specification.
 >
 > 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.
 >
 > -Erik
 >
 > 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
 > software.
 >  > This issue is assuming that the policy is strict validation and 
that the
 >  > 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 http://www.schemavalid.com/faq/xml-schema.html#d4
 >  >
 >  >
 >  >     Can schemas validate parts of an instance document?
 >  >
 >  > Yes, for example XSV <http://www.w3.org/2000/09/webdata/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
 >  > <http://www.w3.org/TR/xmlschema-1/#validation_outcome>: "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 of
 >  > 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 <http://www.w3.org/TR/xmlschema-1/#validation_outcome>.
 >  >
 >  >
 >  >
 >  > 
------------------------------------------------------------------------
 >  > *From:* public-forms-request@w3.org 
[mailto:public-forms-request@w3.org]
 >  > *On Behalf Of *John Boyer
 >  > *Sent:* Thursday, October 18, 2007 5:51 PM
 >  > *To:* ebruchez@orbeon.com
 >  > *Cc:* Forms WG (new); public-forms-request@w3.org
 >  > *Subject:* Re: Major problem with schema needs immediate attention.
 >  >
 >  >
 >  > Hi Erik,
 >  >
 >  > Regarding validate vs. schema attribute on instance, are you 
saying that
 >  > 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 
then,
 >  > 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: boyerj@ca.ibm.com
 >  >
 >  > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >  >
 >  >
 >  >
 >  >
 >  > *Erik Bruchez <ebruchez@orbeon.com>*
 >  > Sent by: public-forms-request@w3.org
 >  >
 >  > 10/18/2007 04:08 PM
 >  > Please respond to
 >  > ebruchez@orbeon.com
 >  >
 >  >
 >  >
 >  > To
 >  >                  "Forms WG (new)" <public-forms@w3.org>
 >  > 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
 > efficient.
 >  >
 >  > 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
 >  > http://www.orbeon.com/
 >  >
 >  >
 >  >
 >
 >
 > --
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
 > http://www.orbeon.com/
 >
 >
 >
 >


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/