HI,

On Tue, 2005-05-03 at 16:05 +0100, Michael Kay wrote: 
> Saxon accepts it as valid.
> 
> I'm not sure if that's right: I think the spec leaves a lot of options in
> this area.

Can you point me to the places where it leaves options here?

This is how I currently read the spec here:
- cvc-assess-elt (1.2) is used, because no known declaration is known
  for the element
- as per cvc-assess-elt (1.2.1.2.1) - (1.2.1.2.3), the local type of
  "boo" resolves to xsd:string - a simple type
- further cvc-assess-elt (1.2.2) leads to cvc-type
- cvc-type allows the attribute "xsi:nil" to be present for simple types
- cvc-type (3.1.3) mentions cvc-elt (3.2), which would normally activate
  the "nilled" mechanism, but does not apply, since there was no
  declaration

So, neither I see a chain of rules where the mechanism of "xsi:nil" is
taken into account, nor a where the attribute itself is disallowed.

Regards,

Kasimier

> 
> Michael Kay
> http://www.saxonica.com/
> 
> > -----Original Message-----
> > From: xmlschema-dev-request@w... 
> > [mailto:xmlschema-dev-request@w...] On Behalf Of Kasimier Buchcik
> > Sent: 03 May 2005 15:23
> > To: XML-SCHEMA
> > Subject: laxly assessed elements, xsi:type and xsi:nil
> > 
> > 
> > Hi,
> > 
> > while toying with laxly assessed elements in combination with 
> > "xsi:type"
> > and "xsi:nil" I stumbled over a scenario where the schema
> > processors XSV 2.8, Xerces-J 2.6.2, MSXML 4.0 and MS.NET all behave
> > differently.
> > 
> > Example:
> > 
> > (any_1.xsd)
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > 	targetNamespace="urn:test:foo"
> > 	elementFormDefault="qualified">	
> > 
> > 	<xsd:element name="foo">
> > 		<xsd:complexType>
> > 			<xsd:sequence>
> > 				<xsd:element name="bar"/>
> > 			</xsd:sequence>
> > 		</xsd:complexType>
> > 	</xsd:element>
> > </xsd:schema>
> > 
> > (any_1.xml)
> > <foo 
> > 	xmlns="urn:test:foo"
> > 	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > 	xsi:schemaLocation="urn:test:foo any_1.xsd">
> > 	<bar>
> > 		<boo xsi:type="xsd:string" xsi:nil="true">abc</boo>
> > 	</bar>
> > </foo> 
> > 
> > Xerces-J 2.6.2 eats it.
> > 
> > XSV 2.8 reports:
> > "element boo is nilled but is not empty".
> > 
> > MSXML 4.0 reports:
> > "xsi:nil attribute on element 'boo' is invalid.".
> > 
> > MS.NET reports:
> > "Das urn:test:foo:boo-Element wurde nicht deklariert. Fehler in
> > 'file:///p:/libxml2-lab/tests/2005-04-26/reader_any_1.xml', '(8 und
> > 4)'."
> > (which means that MS.NET barks about the element "boo" not being
> > declared)
> > 
> > The behaviour of MS.NET is only understandable when assuming that
> > it does not allow "lax" assessment.
> > 
> > MSXML reports the attribute "xsi:nil" as invalid, which seems not
> > correct, since  cvc-type (3.1.1) allows those attributes.
> > 
> > XSV reports the content to be invalid since "nilled", but I cannot
> > find any rule which takes "xsi:nil" into account, when an element
> > declaration is not present. This leads directly to the result
> > of Xerces-J which seems to be the only correct one.
> > 
> > Can someone clarify this?
> > Should we follow Xerces-J here?
> > 
> > Regards,
> > 
> > Kasimier
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 

From John.Hockaday@g... Wed May 04 07:16:41 2005
Received: from bart.w3.org ([128.30.52.40])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1DTE7d-000860-V8
	for