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?
>=20
> regards ... confused. DaveP
>=20
> instance
> <uaffect xmlns=3D"http://www.dpawson.co.uk/ns#" =
xmlns:e=3D"http://example.com">
>    <effect Type=3D"a"  TypeNotes=3D"sss" e:dc=3D"xxx" e:bs=3D"ss" >
>      <ap></ap>
>    </effect>
>    <effect Type=3D"b" e:bs=3D"ss" att2=3D"Not namesapced">
>        <ap>Inherited ns</ap>
>        <ap1 xmlns=3D"">Null namespaced</ap1>
>    </effect>
> </uaffect>
>=20
>=20
> Main schema
> <xsd:schema xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"
> xmlns:d=3D"http://www.dpawson.co.uk/ns#"
>    targetNamespace=3D"http://www.dpawson.co.uk/ns#"
>    xmlns:dp=3D"http://www.dpawson.co.uk/ns#" =
xmlns:e=3D"http://example.com">
>    <xsd:include schemaLocation=3D"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. =20

First, purely syntactically:  the reference to xsd:import must be used=20=

because the target namespace of the schema document referred to=20
(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=20
namespace and its declarations are to be captured (in what is
metaphorically called 'chameleon inclusion'); the reference is=20
performed with xsd:import when the reference is intended to=20
cause components in a foreign namespace to be integrated into
the schema being put together.

=46rom 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=20
schema documents. =20

The distinction between include and import is redundant for cases=20
like this one:  it's obvious to any observer that the two target =
namespaces=20
differ, so the distinction between include and observe is not=20
contributing any information here.  One could easily imagine=20
a surface syntax in which it went away.  The redundancy can=20
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=20
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=20
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=20
import; it's required for include (because otherwise the=20
'include' would have no meaning).


>    <xsd:import schemaLocation=3D"eppNSExtension.xsd"
> namespace=3D"http://example.com"/>
>=20
>    <xsd:element name=3D"uaffect">
>        <xsd:complexType>
>            <xsd:sequence maxOccurs=3D"unbounded">
>                <xsd:element ref=3D"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=3D"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,=20
which is not declared in the schema documents you show. =20

If you want to be able to write ref=3D"effect" and have it mean
{http://www.dpawson.co.uk/ns#}effect, you could do so by writing

  <xsd:element ref=3D"effect"=20
    xmlns=3D"http://www.dpawson.co.uk/ns#"/>

or equivalently by adding=20

  xmlns=3D"http://www.dpawson.co.uk/ns#"=20

to some containing element (the xsd:schema element would=20
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.=20


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



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=20
the target namespace as the default namespace, and (if you
want local elements to be namespace-qualfieid, using=20
elementFormDefault on the schema element).

I hope this helps.

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