RE: 'form' property under schema composition

	
>	Your answer in (a) means that the same 'form' value (explicit or
implicit) that I'd calculate for an element or for an attribute in the same
XML Schema file or document should be expected when this file is
participating in schema compositions, i.e., being included and/or imported.
Is that correct?

Yes, I think so. "form" appears only in the XML representation, not in the
schema component model. In 3.3.2, for local element declarations, we read:

{target namespace}	If form is present and its .actual value. is
qualified, or if form is absent and the .actual value. of elementFormDefault
on the <schema> ancestor is qualified, then the .actual value. of the
targetNamespace [attribute] of the parent <schema> element information item,
or .absent. if there is none, otherwise .absent..

Include and import operations do not change the <schema> ancestor of an
<element> element information item. So I think this is perfectly clear.

	
>	If a top level element or attribute in a chameleon schema (the file
they are defined in does not define a target namespace but the
importing/including schema does) then they are qualified in the target
namespace of the importing/including schema. Is that correct?

Yes. See 4.2.1, Schema Representation Constraint: Inclusion Constraints and
Semantics, rule 3.2.1. Note that in this rule "code" should read "form".
	
>	What happens to unqualified (form='unqualified') top level elements
and attributes that are being imported/included into another schema that has
a target namespace defined? I suspect that they remain unqualified. Is that
correct?

The 1.0 spec is a little bit unsatisfactory in this area, because it talks
about xs:include operating at the level of schema components, and then it
talks about declarations "whose code [sic, read form] was qualified" as if
the schema component has some memory of the original XML representation.
It's also rather unsatisfactory to have rules expressed in the subjunctive
"anywhere the absent targetNamespace would have appeared [if it were not
absent]". But given these infelicities, I think one can only read the spec
as meaning that unqualified declarations remain unqualified.

The 1.1 specification has cleaned this up significantly. It defines
chameleon include as being the inclusion of a schema document created by
taking the referenced document and transforming it to add a targetNamespace
attribute to the <schema> element.


Michael Kay
http://www.saxonica.com/


	
	Shlomo.
	
	-----Original Message-----
	From: Michael Kay [mailto:mike@saxonica.com]
	Sent: Wed 1/2/2008 3:52 PM
	To: Shlomo Yona; xmlschema-dev@w3.org
	Subject: RE: 'form' property under schema composition
	
	I think the rules are as follows:
	
	(a) if "form" isn't specified for an element or attribute, then the
	formDefault attribute of the textually containing xs:schema element
provides
	the default. The formDefault attribute of an including/importing
schema does
	not affect the value.
	
	(b) if the resulting value is "qualified", then the element or
attribute
	name is qualified by the target namespace of the schema document. In
the
	case of a chameleon include, this is the targetNamespace of the
including
	schema document.
	
	Michael Kay
	http://www.saxonica.com/
	
	
	  _____ 
	
	From: xmlschema-dev-request@w3.org
[mailto:xmlschema-dev-request@w3.org] On
	Behalf Of Shlomo Yona
	Sent: 24 December 2007 07:18
	To: xmlschema-dev@w3.org
	Subject: 'form' property under schema composition
	
	
	
	
	Hello,
	
	I am confused about the expected behavior of the 'form' property for
	elements and for attributes under schema composition operations.
	
	How should the 'form' property of elements and of attributes (top
level and
	internal) be affected upon schema composition operations
(xsd:include,
	xsd:import and xsd:redefine) when targetNamespace is (or isn't)
defined in
	the included/imported document and a targetNamespace is defined in
the
	including/importing document?
	
	Are they supposed to maintain their 'form' property? Should they
take the
	'form' property induced by the importing/including document? Does
the
	expected behavior change if elementFormDefault/attributeFormDefault
is
	defined in the importing/including document or in the
imported/included
	document (or both)? Does it matter whether or not 'form' property is
	explicitly listed for an element/attribute in these cases?
	
	While I think that the following is clear, I am not clear about the
	remaining cases:
	1. top level names in a schema document with no target namespace are
	unqualified
	2. top level names in a schema document with a target namespaces are
	qualified
	3. top level names in a schema document with no target namespace
that are
	included/imported into a schema document that has a target namespace
are
	qualified
	
	Is that true?
	
	What is the expected behavior in all the cases that are not one of
the above
	listed 3 cases?
	
	Thanks.
	
	Shlomo

Received on Thursday, 3 January 2008 11:22:35 UTC