Re: Add an attribute

On Mar 22, 2013, at 4:52 AM, Dave Pawson wrote:

> Fixed, but the solution looks 'orrible.
> Is it possible to make it tidier than this?
> 
> regards ... confused. DaveP
> 
> instance
> <uaffect xmlns="http://www.dpawson.co.uk/ns#" xmlns:e="http://example.com">
>    <effect Type="a"  TypeNotes="sss" e:dc="xxx" e:bs="ss" >
>      <ap></ap>
>    </effect>
>    <effect Type="b" e:bs="ss" att2="Not namesapced">
>        <ap>Inherited ns</ap>
>        <ap1 xmlns="">Null namespaced</ap1>
>    </effect>
> </uaffect>
> 
> 
> Main schema
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:d="http://www.dpawson.co.uk/ns#"
>    targetNamespace="http://www.dpawson.co.uk/ns#"
>    xmlns:dp="http://www.dpawson.co.uk/ns#" xmlns:e="http://example.com">
>    <xsd:include schemaLocation="eppExtensions.xsd"/>
>    <!-- Why must it be imported? Just to get the namespace attr? -->

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.

From a design point of view:  XSD's surface syntax reflects
the assumption that schema components in different namespaces
are likely to have different owners and different maintenance schedules;
XSD tries to support this by making declarations for them go into distinct 
schema documents.  

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

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).


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


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

>    <xsd:element name="effect" >
>        <xsd:complexType>
>            <xsd:sequence>
>                    <!-- ap is in the default ns, but xsd needs to be
> told that -->
>                <xsd:element name="ap" type="xsd:string" minOccurs="1"
> form="qualified"/>
>                <!-- But ap1 is in 'no' namespace.... -->
>                <xsd:element name="ap1" type="xsd:string" minOccurs="0"/>
> 
>            </xsd:sequence>
>            <xsd:attribute name="Type" type="xsd:token" use="required"/>
>            <xsd:attribute name="TypeNotes" type="xsd:string"/>
> 
>            <!-- External additions  -->
>            <xsd:attributeGroup ref="dp:extgp1"/>
>            <xsd:attributeGroup ref="e:extgp2"/>
>        </xsd:complexType>
>    </xsd:element>
> 
> 
> 
> </xsd:schema>
> 
> First (non-ns additions)
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:dct="http://purl.org/dc/terms/"
>    xmlns:atom="http://www.w3.org/2005/Atom"
> attributeFormDefault="unqualified" version="1.0"
>    targetNamespace="http://www.dpawson.co.uk/ns#" id="eppExtensions">
> 
>    <!--   This attribute is not namespaced  See attributeFormDefault -->
>    <!--  Use this form for non-namespaced atts -->
>    <xsd:attributeGroup name="extgp1">
>        <xsd:attribute name="att2" type="xsd:string"/>
>    </xsd:attributeGroup>
> </xsd:schema>
> 
> 
> Second (namespaced) additions
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
>    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:dct="http://purl.org/dc/terms/"
>    xmlns:atom="http://www.w3.org/2005/Atom"
> targetNamespace="http://example.com"
>    xmlns:e="http://example.com"
>    xmlns:d="http://example.com" attributeFormDefault="qualified"
> version="1.0" id="eppExtensions">
> 
> 
> 
>    <xsd:attributeGroup name="extgp2">
>        <xsd:attribute name="bs" type="xsd:string" use="required"
> form="qualified"/>
>        <xsd:attribute name="dc" type="xsd:string"/>
>        <xsd:attribute name="bes" type="xsd:string"/>
>    </xsd:attributeGroup>
> 
> 
> </xs:schema>
> 



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.

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

Received on Sunday, 31 March 2013 21:27:07 UTC