Re: LC 124 text, 2 proposals.

The following is my understanding of "validity=notKnown" in schema. 
Without knowing all the background around this discussion, I may be saying 
something that's trivial or unrelated at all, in which case please kindly 
ignore this message.

Arthur is quite right in saying that 

> [validity]=notKnown means the processor ... did not attempt a strict 
assessment.

For a complex content:

<sequence>
  <element name="e1"/>
  <any processContents="skip"/>
  <element name="e3"/>
</sequence>

and the instance #1

<e1/><e2/><e3/>

The validity of "e2" is notKnown, because no element declaration or type 
definition is available to assess it. For the instance #2

<e1/></e2/><e4/>

or #3

<e1/></e2/><e3/><e4/>

The validity of "e4" is also notKnown, because, again, there is no element 
declaration or type definition to assess it. (Though "e4"'s parent will be 
marked as invalid.)

The same applies to attributes.

If there is a global element declaration for "e2" (in the schema), or if 
there is an resolvable xsi:type attribute on "e2" (in the instance), then 
the *intention* of the schema spec is still to make the [validity] 
notKnown, though the current spec fails to describe that (or at least is 
not clear).

If there is a global element declaration for "e4" (in the schema), or if 
there is an resolvable xsi:type attribute on "e4" (in the instance), then 
the current spec suggests that "e4" should be strictly assessed using the 
element decl or the resolved xsi:type, hence its validity is either valid 
or invalid. I think this is reasonable, and it's probably intended, but 
not 100% sure.

Note that I used the word "resolvable" in the above 2 paragraphs. If the 
xsi:type attribute value is not resolvable to a type definition, then it's 
*not* an error for either "e2" or "e4". It only makes it impossible to 
perform strict assessment on these elements, and makes the validity 
notKnown.

Thanks,
Sandy Gao
XML Parser Development, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com




Arthur Ryman/Toronto/IBM
07/08/2005 03:45 PM

To
"David Orchard" <dorchard@bea.com>
cc
www-ws-desc@w3.org, www-ws-desc-request@w3.org, Sandy 
Gao/Toronto/IBM@IBMCA
Subject
Re: LC 124 text, 2 proposals.





David,

I read the XML Schema spec and got a very different interprettation of 
notKnown. I got the impression that [validity]=notKnown means the 
processor doesn't know if the item is valid or invalid, i.e. it did not 
attempt a strict assessment.

Can a Schema guru pls clarify this?

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/



"David Orchard" <dorchard@bea.com> 
Sent by: www-ws-desc-request@w3.org
06/30/2005 03:18 PM

To
<www-ws-desc@w3.org>
cc

Subject
LC 124 text, 2 proposals.






Based upon the straw poll that shows "option 4 : can set in endpoint only 
if unset in types" a winner, and the "default on" straw poll option of 
"Option 4: combo prop: def is on, set to off in types and endpoints but 
endpoint can't set to ON", I offer 2 proposals:
 
Option #1: Default On
=================
3 Types
3.1 The Types Component
A types component defines the types that constrain messages and faults.
 
The properties of the types component are as follows:
·         {ignoreUnknown} REQUIRED. An xs:binary. 
 
The "ignoreUnknown" property set to "true" denotes that the type accepts 
without faulting additional _unknown items_ in messages using the type. 
_Unknown items_ are attributes and elements not defined by the schema for 
a particular element in the type.  _Unknown items_ may appear in any 
namespace including the targetNamespace of a known schema, as well as in a 
namespace for which no schema is currently known.  _Unknown items_ 
includes the descendents of the item, such any child elements, attributes 
and content. 
 
Note: one mechanism for accomplishing this is to validate a message after 
content that is not known has been removed.  The unknown content may be 
identified by a W3C XML Schema processor.  The [validity] property in the 
Post Schema-Validation Infoset will contain a "notKnown" value if unknown 
content is found.
 
3.2 Types XML Representation
(From current section 3 Types section)
 
  Add an ignoreUnknown attribute
 
3.3 Mapping Type's XML Representation to Component Properties
The mapping from the XML Representation of the types element information 
item (see 3.2 XML Representation of types Component) to the properties of 
the Types component is as described in Table 3-1. 
 

Table 3-1. Mapping from XML Representation to Types Component Properties
Property
Value
{ignoreUnknown}
The actual value of the ignoreUnknown attribute information item if 
present, and true otherwise. 
 
 
Extensions to 3.15 
  Add an {ignoreUnknown} Boolean property to the endpoint component.
  Add an ignoreUnknown attribute to <wsdl:endpoint>
  Map the attribute to the property by mapping the declared value of the 
attribute into the property.  When the attribute is missing, the value of 
the property is the value of the types component {ignoreUnknown} property. 
 It is illegal for the endpoint component {ignoreUnknown} property to be 
set to true if the types component {ignoreUnknown} property is false.
 
Option #2: Default Off
================
 
Change Table 3-1 to say "and false otherwise"