Re: Major problem with schema needs immediate attention.

John & all,

 > 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?

Let's assume this:

   xmlns:a="A"
   xmlns:b="B"

If A.xsd contains a top-level definition for a:e, then the instance
will be validated according to this type. Only in the case where A.xsd
specifies some lax validation further down would definitions from
B.xsd apply. Otherwise, only the type for a:e will be used for
validation.

To make things even clearer, if you add the XSLT 2.0 @type attribute,
then you can say:

   <instance type="a:e">
     <e xmlns="A"/>
   </instance>

Then you make sure that the whole instance matches exactly a:e, and
something like this:

   <instance type="a:e">
     <dummy xmlns="A"/>
   </instance>

will be invalid. Since we have the @type MIP, maybe we don't need this
attribute, although it would be a very convenient shortcut. Compare
with adding this:

   <bind nodeset="instance('my-instance')" type="a:e"/>

Here is maybe a better use case for lax validation. Assume your
instance contains an XHTML document:

<instance validation="lax">
   <xhtml:html>
     ...
   </xhtml:html>
</instance>

That document may contain XForms and XML Events attributes and
elements. Assume also that you are importing a schema for XForms and
one for XML Events, but you don't have a schema for XHTML:

   <xforms:model schema="xforms.xsd xmlevents.xsd">

Then you see here how LAX validation will kick in and validate both
XForms and XML Events definitions, but will not mark XHTML elements
and attributes as invalid.

 > 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.

I don't necessarily dislike as a new feature allowing the form author
to specify schemas scoped by instance. But this still doesn't tell
XForms how to validate that instance using the schema or schemas
provided. I can see how this could be useful in addition to the XSLT
2.0 validation attributes.

 > 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.

I don't really see a compelling reason for this. The type MIP already
allows validating nodes based on imported schema types. I think it's
pretty clear at the moment that those will be validated in a "strict"
way, i.e. if I say that this node is of type my:employee, it better be
of this type.

Lax and strict validation on the other hand are a way of letting the
schema validator loose on an instance, without going through the
trouble of adding binds all over the place.

 > 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.

I reckon that we (and our predecessors) did good work in XForms to
leverage existing specs. I am just encouraging us to keep doing so.

 > 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.

I do see a good point about the ability to specify schemas per
instance, but besides that I have yet to see a demonstration that we
are really trying to solve another problem than XSLT 2.0.

-Erik

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

Received on Friday, 19 October 2007 20:41:19 UTC