- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Wed, 31 Oct 2007 17:59:56 -0700
- 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