Re: Add an attribute

On Apr 1, 2013, at 1:40 AM, Dave Pawson wrote:

> 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?

Yes; chameleon include was a consciously designed feature
intended to help in cases where multiple namespaces are
to have structurally identical sets of elements.  It turns out to be
useful also when it's not clear until late in the design process 
whether a given set of elements is intended to be in one 
namespace or another, or both, or neither:  that set of 
elements can be specified in a schema document without any
target namespace, and put into one or more namespaces 
by using chameleon include.

>> 
>> 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/ ?

Yes, thank you.

> 
>> 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?

Yes, if it's possible to separate them.  But since include doesn't
carry a @namespace attribute, using include for both same-ns
and different-ns references would not achieve the redundancy
and would not allow for the detection of simple errors.  But yes,
it's not just the generic identifiers 'include' and 'import' that make
the error detection possible, but the combination of the difference
in element types and the difference in the attributes they carry.
> ...
> 
>> 
>> 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?

There were certainly WG members who were concerned
that their validators not be required to have a network
connection to work, and that they be able to work from a 
local repository of known schemas for specific namespaces.
Database vendors, in particular, tend to want to push
schema-aware decisions as far down in their software as
they can (I believe for speed reasons), and to want early
binding of namespaces to schemas rather than late binding.

In some specs, the requisite freedom for implementations 
is handled by everyone observing sagely that a request to
dereference a URI doesn't necessarily mean an HTTP 
request to the host named and that the local repository of
schemas can be regarded (with a suitable squint) as being
what a proxy server returns when invited to dereference a
schema for a known namespace.  For some mix of historical,
psychological, and/or technical reasons that I am not sure
any single person in the WG could explain or understand,
that view didn't get much traction in the XML Schema WG,
and so XSD has this slightly unusual characteristic of
defining certain URI references as hints and not as
instructions.  

It does make the spec harder to understand, and it does
make for some interoperability issues -- just knowing that
a validator claims conformance to the spec does not enable
us to know what a validator is going to do when it sees an
import element.
> ...
> 
> 
>> 
>> 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?

The XML Schema WG has not, I fear, been as successful as some
WGs in providing readable accounts of its design goals.  I think
the tutorial for XSD 1.0 edited by David Fallside (part 0 of the
1.0 Rec) may help in some ways; otherwise, your best bet may
be one of the various books on XSD.  I don't know them all and
can't make any specific recommendations, but I have heard good
things about the books by (in alpha order) Berthold Daum,
Eric van der Vlist, and Priscilla Walmsley.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Monday, 1 April 2013 15:13:26 UTC