RE: Major problem with schema needs immediate attention.

Erik,
In this case, the rules I provided would assume strict processing
because there is a schema for the namespace.
The form author who has read access to the schema can always write a new
external or inline xs:schema that includes the existing schema an
decorates it, giving you control over processing-mode and still
preserving the one-xsd-per-schema rule and giving you access to the full
control of the schema engine.

This issue as I see it is about what to do when the form author collects
an unrelated set of schemas together in the schema attribute and wants
some easy default behavior without inline xs:schema elements.

Everybody agrees that post 1.1 we should align more closely with XSLT
2.0 and that the use cases for being able to specify schema processing
as lax or strict in a more fine-grained way is important, but bolting it
on at this stage in 1.1 is likely to cause design problems, and will
also be one more instance of taking things piecemeal from XSLT 2.0.

Leigh.


-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
On Behalf Of Erik Bruchez
Sent: Thursday, November 01, 2007 6:54 PM
To: Forms WG (new)
Subject: Re: Major problem with schema needs immediate attention.


...

 > All prior versions of the spec do not say what kind of validation is
 > performed, they simply reference XML Schema 1.0, which by my read
 > means that strict processing is what occurs in the absence of a
 > processContent declarations to the contrary in the schema.

How sure of this are we? If I say:

   ./my-xsd-valiator data.xml schema.xml

with data.xml:

   <foo:baaaar>
     ...
   </foo:baaaar>

and schema.xml specifying a target namespace for foo, but no type for
foo:baaaar, what will happen? And would all validators even agree with
what to do?

Received on Friday, 2 November 2007 17:13:33 UTC