[w3c sml] [4775] Change "skip" to "lax" processing

All,

 

The email will serve to initiate the discussion of whether we should
specify processControl="lax" rather than the current "skip" for
wildcards in the SML XML Schemas.

 

There is only one occurrence of processControl="skip" in the SML
specification: for the content of the smlerr:errorDataType.

 

The original issue was raised with respect SML-IF in which
processControl="skip" is used for all extension elements (both xs:any
and xs:anyAttribute) in the type definitions of this specification.

 

Since I wasn't involved in the original authorship of the spec, I'm not
sure what the rationale was for the original use of "skip".  I assume it
was for efficiency of the SML-IF consumer, the assumption being that the
SML-IF would need to concern itself only with sml elements according to
the semantics specified in SML-IF.  In my notes I have found the
following definition of an SML-IF consumer: "processes SML-IF documents
in whole or in part by the semantics of this specification" (emphasis
added).  Since, by definition, extension elements lie beyond the
semantics of the spec, there appears to be no reason for the processor's
attempting to validate the extension elements.  But I would consider
this a poor argument.

 

"Skip" seems too finalistic and may not meet the requirements of SML-IF
consumer creators and SML-IF document authors who need to build in
special information, eg., into the ModelType, and can provide the schema
for validation (assessment).  I suspect that something like this
rationale underlies what appears to be the industry "best practice" of
using "lax" processing.   The cost of using lax processing is
undoubtedly absolutely minimal.

 

I will recommend changing the spec to "lax", according to what is
industry best practice.  

 

Kirk Wilson, Ph.D.
CA Inc.
Research Staff Member, CA Labs
Intellectual Property and Standards
Council of Technical Excellence
W3C Advisory Committee Representative

Tele: + 1 603 823-7146
Fax:   + 1 603 823-7148
<mailto:kirk.wilson@ca.com> 

 

Received on Friday, 24 August 2007 14:50:31 UTC