W3C home > Mailing lists > Public > public-forms@w3.org > November 2007

Re: Major problem with schema needs immediate attention.

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 31 Oct 2007 17:59:56 -0700
Message-ID: <4729250C.80309@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>

Leigh,

I don't understand this. Assume lax processing only.

Case 1: I have NO schema containing element definitions for the null 
namespace, AND I have this instance:

<xforms:instance>
   <foo xmlns="">
     ... more stuff ...

Case 2: I have NO schema containing element definitions for the bar 
namespace, AND I have this instance:

<xforms:instance>
   <bar xmlns="bar">
     ... more stuff ...

In both case, I expect the same behavior, i.e. the root element of 
either instance is processed in a lax way, i.e. lax processing keeps 
going and attempts to validate attributes and children elements.

What's wrong with that?

-Erik

Klotz, Leigh wrote:
> John,
> I'm having trouble following this.
>  
> I don't think special casing the xmlns="" is a good idea either, but I 
> want to make sure we've captured what current processors are doing, 
> which is the goal of 1.1/
>  
> If we don't special case the no-namespace then the use of any structure 
> schema on xmlns="" will require the use of schema structure for all 
> elements.
> That's the opposite of what your first paragraph says, I think.
>  
> I agree that fine-grained controls are for a later revision and don't 
> want to debate them now.
>  
> I don't think we've come to closure yet so I can't say what or where we 
> put in.
>  
> Leigh.
> 
> ------------------------------------------------------------------------
> *From:* John Boyer [mailto:boyerj@ca.ibm.com]
> *Sent:* Wednesday, October 31, 2007 2:00 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.
> 
> 
> 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/
> 
> 
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Thursday, 1 November 2007 01:00:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:46 UTC