Thank you very much for the references to the schema spec and your =
additional commentary.

Finally -- if no 'form' is explicitly defined and =
elementFormDefault/attributeFormDefault is not explicitly assigned with =
a value then are top level elements and attributes of such a schema =
document unqualified after they are imported/included?

Thanks again

Shlomo

-----Original Message-----
From: Michael Kay [mailto:mike@s...]
Sent: Thu 1/3/2008 1:22 PM
To: Shlomo Yona; xmlschema-dev@w...
Subject: RE: 'form' property under schema composition
 
=09
>	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.

=09
>	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".
=09
>	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/


=09
	Shlomo.
=09
	-----Original Message-----
	From: Michael Kay [mailto:mike@s...]
	Sent: Wed 1/2/2008 3:52 PM
	To: Shlomo Yona; xmlschema-dev@w...
	Subject: RE: 'form' property under schema composition
=09
	I think the rules are as follows:
=09
	(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.
=09
	(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.
=09
	Michael Kay
	http://www.saxonica.com/
=09
=09
	  _____ 
=09
	From: xmlschema-dev-request@w...
[mailto:xmlschema-dev-request@w...] On
	Behalf Of Shlomo Yona
	Sent: 24 December 2007 07:18
	To: xmlschema-dev@w...
	Subject: 'form' property under schema composition
=09
=09
=09
=09
	Hello,
=09
	I am confused about the expected behavior of the 'form' property for
	elements and for attributes under schema composition operations.
=09
	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?
=09
	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?
=09
	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
=09
	Is that true?
=09
	What is the expected behavior in all the cases that are not one of
the above
	listed 3 cases?
=09
	Thanks.
=09
	Shlomo
=09
=09
=09