Re: Add an attribute

Thanks Michael, fairly comprehensive answer.
Some comments in line.


On 31 March 2013 22:26, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
>
>
> I guess you mean "why must the reference to schema document
> 'eppNSExtension.xsd' use xsd:import instead of xsd:include
> (like the reference to epExtensions.xsd)?"  (If that's not what you
> mean, this answer won't help.)
>
> There are several ways to answer this.
>
> First, purely syntactically:  the reference to xsd:import must be used
> because the target namespace of the schema document referred to
> (namely http://example.com) differs from the target namespace of the
> schema document containing the reference.  That's the rule.  The
> reference is performed with xsd:include when either the namespace
> differs or when the schema document referred to has no target
> namespace and its declarations are to be captured (in what is
> metaphorically called 'chameleon inclusion'); the reference is
> performed with xsd:import when the reference is intended to
> cause components in a foreign namespace to be integrated into
> the schema being put together.

Nice clear explanation of chameleon, thanks.
I wonder if this was intentional on the part of the WG?


>
> The distinction between include and import is redundant for cases
> like this one:  it's obvious to any observer that the two target namespaces
> differ, so the distinction between include and observe is not

s/observe/import/ ?

> contributing any information here.  One could easily imagine
> a surface syntax in which it went away.  The redundancy can
> be used, however, to provide some simple checking:  because
> you specify the namespace 'http://example.com' both on the
> import and on the schema document imported, the processor
> has a chance to detect at least some errors that would otherwise
> be undetectable.  That's a second reason that you need to use
> import here.

A facet of the @targetNamespace or @namespace metadata surely,
rather than the use of import|include?

>
> A third  is that although the include/import distinction carries no
> new information here, it does carry such information for cases where
> the schema document being referred to has no target namespace:
> in such a case, 'include' causes a chameleon-include of the
> material in the other schema document, while 'import' incorporates
> components with unqualified names into the schema.

Thanks, again clear.

>
> A fourth reason is that 'schemaLocation' has a slightly
> different meaning on the two elements.  For 'include', the
> schemaLocation attribute specifies a resource which a
> conforming web-aware processor is required to dereference;
> for 'import' it's a hint, which a conforming processor may
> ignore (it may, for example, have a local repository with the
> preferred schemas for particular namespaces).  Even more
> important, schemaLocation is optional, not required, for
> import; it's required for include (because otherwise the
> 'include' would have no meaning).

I guess there is some implementers logic in there,
darned if I can see it? Import this... but I'm not going
to tell you where from? Go guess ("implementation dependent"?)
  Was this some WG member with an agenda wanting to
take this home as a #win?

>
>
> >    <xsd:import schemaLocation="eppNSExtension.xsd"
> > namespace="http://example.com"/>
> >
> >    <xsd:element name="uaffect">
> >        <xsd:complexType>
> >            <xsd:sequence maxOccurs="unbounded">
> >                <xsd:element ref="dp:effect"/>    ?????????????? why
> > must @ref be ns'd??????
>
> The value of @ref is a QName, interpreted using the namespace
> bindings of the xsd:element on which the @ref attribute occurs.
> It's not quite true to say that the value of @ref must be a prefixed
> value, nor that it must be a namespace-qualified value; it would be
> completely legal to write <xsd:element ref="effect"/> -- it's just
> that what you show refers to the element whose expanded name
> is {http://www.dpawson.co.uk/ns#}effect, and given the namespace
> bindings in force here a reference to "effect" instead of "dp:effect"
> would refer to an element whose expanded name is {}effect,
> which is not declared in the schema documents you show.
>
> If you want to be able to write ref="effect" and have it mean
> {http://www.dpawson.co.uk/ns#}effect, you could do so by writing
>
>   <xsd:element ref="effect"
>     xmlns="http://www.dpawson.co.uk/ns#"/>
>
> or equivalently by adding
>
>   xmlns="http://www.dpawson.co.uk/ns#"
>
> to some containing element (the xsd:schema element would
> be a natural choice).  That would have the effect of requiring
> special effort to refer to non-namespaced components, which
> might or might not be a problem in a particular case.

Thanks, very clear Michael.



>
>
> >            </xsd:sequence>
> >        </xsd:complexType>
> >    </xsd:element>
> >
> > <!-- effect is in the default namespace -->
>
> I think you mean that the element declared here is in the
> target namespace of the schema document.

<grin/> No, I was wrong.

>  It's not the default
> namespace in the usual sense of that word -- at least, not
> unless and until you use a default namespace declaration
> to make it so, as described above.
>



>
> You ask "Is it possible to make it tidier than this?"  I think you
> have it right, and about as tidy as it comes.  You can simplify
> bits and pieces of it, if you like -- or at least shorten them (in
> a way that not everyone will think of as "simpler") by declaring
> the target namespace as the default namespace, and (if you
> want local elements to be namespace-qualfieid, using
> elementFormDefault on the schema element).
>
> I hope this helps.

Likely more so when I've read it a couple more times,
Appreciated Michael.
   Is there a paper explaining some of these 'philosophies' of xsd out
there please?
 for the user, not the implementer?

regards DaveP



--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Monday, 1 April 2013 07:40:51 UTC