Add an attribute

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Add an attribute

Dave Pawson-2
I'm extending a schema. vsn 1.0 using oXygen, xerces parser
main schema is in namespace ns1
I want to add an attribute group, all attributes in ns2

to give
<a:element att1='x' b:att2='y'/>

To keep it clean, I would like the attribute group to be defined in a
second file
and imported into the main schema.

the main schema has

 <xsd:include schemaLocation="eppExtensions.xsd"/>
    <xsd:include schemaLocation="eppNSExtension.xsd"/>

 <xsd:element name="a">
 ...
 <xsd:attribute name="Type" type="xsd:token" use="required"/>
  <xsd:attributeGroup ref="extgp1"/>
   <xsd:attributeGroup ref="extgp2"/>
</xsd:element>


att1 is defined in file1, works fine

I can't figure out the syntax to put the second attribute group extgp1
into a ns?

The second included file is

<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"
    id="eppExtensions">

    <xsd:attributeGroup name="extgp1">
        <xsd:attribute name="att2" type="xsd:string"/>
    </xsd:attributeGroup>
</xsd:schema>

Any suggestions please? To read / learn or fix the syntax?

TiA

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

Reply | Threaded
Open this post in threaded view
|

Re: Add an attribute

Dave Pawson-2
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? -->
    <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??????
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>

<!-- effect is in the default namespace -->
    <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>





On 22 March 2013 10:02, Dave Pawson <[hidden email]> wrote:

> I'm extending a schema. vsn 1.0 using oXygen, xerces parser
> main schema is in namespace ns1
> I want to add an attribute group, all attributes in ns2
>
> to give
> <a:element att1='x' b:att2='y'/>
>
> To keep it clean, I would like the attribute group to be defined in a
> second file
> and imported into the main schema.
>
> the main schema has
>
>  <xsd:include schemaLocation="eppExtensions.xsd"/>
>     <xsd:include schemaLocation="eppNSExtension.xsd"/>
>
>  <xsd:element name="a">
>  ...
>  <xsd:attribute name="Type" type="xsd:token" use="required"/>
>   <xsd:attributeGroup ref="extgp1"/>
>    <xsd:attributeGroup ref="extgp2"/>
> </xsd:element>
>
>
> att1 is defined in file1, works fine
>
> I can't figure out the syntax to put the second attribute group extgp1
> into a ns?
>
> The second included file is
>
> <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"
>     id="eppExtensions">
>
>     <xsd:attributeGroup name="extgp1">
>         <xsd:attribute name="att2" type="xsd:string"/>
>     </xsd:attributeGroup>
> </xsd:schema>
>
> Any suggestions please? To read / learn or fix the syntax?
>
> TiA
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk



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

Reply | Threaded
Open this post in threaded view
|

Re: Add an attribute

C. M. Sperberg-McQueen-2

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





Reply | Threaded
Open this post in threaded view
|

Re: Add an attribute

Dave Pawson-2
Thanks Michael, fairly comprehensive answer.
Some comments in line.


On 31 March 2013 22:26, C. M. Sperberg-McQueen <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Add an attribute

C. M. Sperberg-McQueen-2

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 <[hidden email]> 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
****************************************************************