W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2008

RE: 'form' property under schema composition

From: Michael Kay <mike@saxonica.com>
Date: Thu, 3 Jan 2008 11:58:51 -0000
To: "'Shlomo Yona'" <S.Yona@F5.com>, <xmlschema-dev@w3.org>
Message-ID: <008b01c84e00$01fd4080$6401a8c0@turtle>
 > Finally -- if no 'form' is explicitly defined and
elementFormDefault/attributeFormDefault is not explicitly assigned with a
I think that case is exactly the same as specifying form="unqualified".
Michael Kay
 then are top level elements and attributes of such a schema document
unqualified after they are imported/included?

Thanks again


-----Original Message-----
From: Michael Kay [ <mailto:mike@saxonica.com> mailto:mike@saxonica.com]
Sent: Thu 1/3/2008 1:22 PM
To: Shlomo Yona; xmlschema-dev@w3.org
Subject: 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

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/> http://www.saxonica.com/

        -----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
        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
        name is qualified by the target namespace of the schema document. In
        case of a chameleon include, this is the targetNamespace of the
        schema document.
        Michael Kay
         <http://www.saxonica.com/> http://www.saxonica.com/
        From: xmlschema-dev-request@w3.org
[ <mailto:xmlschema-dev-request@w3.org> mailto:xmlschema-dev-request@w3.org]
        Behalf Of Shlomo Yona
        Sent: 24 December 2007 07:18
        To: xmlschema-dev@w3.org
        Subject: 'form' property under schema composition
        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:import and xsd:redefine) when targetNamespace is (or isn't)
defined in
        the included/imported document and a targetNamespace is defined in
        including/importing document?
        Are they supposed to maintain their 'form' property? Should they
take the
        'form' property induced by the importing/including document? Does
        expected behavior change if elementFormDefault/attributeFormDefault
        defined in the importing/including document or in the
        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
        2. top level names in a schema document with a target namespaces are
        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
        Is that true?
        What is the expected behavior in all the cases that are not one of
the above
        listed 3 cases?
Received on Thursday, 3 January 2008 11:59:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:45 UTC