Restriction error

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

Restriction error

Dave Pawson-2
Very new to xsd

Schema part
<xs:complexType name="DCMIType">
   <xs:simpleContent>
    <xs:restriction base="dc:SimpleLiteral">
        <xs:simpleType> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
          <xs:restriction base="dcmitype:DCMIType"/>
        </xs:simpleType>
        <xs:attribute ref="xml:lang" use="prohibited"/>
    </xs:restriction>
   </xs:simpleContent>
  </xs:complexType>

when validating an instance to a schema which includes this block, the arrowed
line is being pointed out as in error.
Validating via oXygen 14.2, using saxon


The report is A complex type with simple content {defined at line 196
        of file:/t...} cannot be derived by restriction from a simple
        type

I've read that ten times and it makes little sense.

Can anyone suggest a change to the schema snippet to clarify/remove
the error please?


TiA




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

Reply | Threaded
Open this post in threaded view
|

Re: Restriction error

Maik Stührenberg
Hi Dave,

I cannot reproduce your error message in oXygen 14.2 (build 2013030817)
with this schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcmitype="http://purl.org/dc/dcmitype/">
   <xs:import namespace="http://purl.org/dc/dcmitype/"
schemaLocation="dcmitype.xsd"/>
   <xs:import namespace="http://purl.org/dc/elements/1.1/"
schemaLocation="dc.xsd"/>
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="xml.xsd"/>
   <xs:complexType name="DCMIType">
     <xs:simpleContent>
       <xs:restriction base="dc:SimpleLiteral">
         <xs:simpleType>
           <xs:restriction base="dcmitype:DCMIType"/>
         </xs:simpleType>
         <xs:attribute ref="xml:lang" use="prohibited"/>
       </xs:restriction>
     </xs:simpleContent>
   </xs:complexType>
</xs:schema>

Neither saxon nor xerces raise an error.

Could you check your build version?

Regards,

Maik Stührenberg

Dave Pawson schrieb:

> Very new to xsd
>
> Schema part
> <xs:complexType name="DCMIType">
>     <xs:simpleContent>
>      <xs:restriction base="dc:SimpleLiteral">
>          <xs:simpleType>  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>            <xs:restriction base="dcmitype:DCMIType"/>
>          </xs:simpleType>
>          <xs:attribute ref="xml:lang" use="prohibited"/>
>      </xs:restriction>
>     </xs:simpleContent>
>    </xs:complexType>
>
> when validating an instance to a schema which includes this block, the arrowed
> line is being pointed out as in error.
> Validating via oXygen 14.2, using saxon
>
>
> The report is A complex type with simple content {defined at line 196
> of file:/t...} cannot be derived by restriction from a simple
> type
>
> I've read that ten times and it makes little sense.
>
> Can anyone suggest a change to the schema snippet to clarify/remove
> the error please?
>
>
> TiA
>
>
>
>

--
Dr. Maik Stührenberg
Universität Bielefeld
Fakultät für Linguistik und Literaturwissenschaft
Universitätsstraße 25
33615 Bielefeld
Telefon: +49 (0)521/106-2534
E-Mail: [hidden email]
http://www.maik-stuehrenberg.de
http://www.xstandoff.net


Reply | Threaded
Open this post in threaded view
|

Re: Restriction error

Michael Kay
In reply to this post by Dave Pawson-2
A complex-type-with-simple-content is generally defined by extension:
think of it as first defining the simple content of the element, then
extending it to allow attributes.

You can define a c-t-with-s-c as a restriction of another c-t-with-s-c,
but that doesn't seem to be what you are doing here; the suggestion from
the error message is that dc:SimpleLiteral is a simple type, not a
c-t-with-s-c.

Difficult to correct this without knowing what you are trying to
achieve. Why are you saying xml:lang is prohibited? Does your new type
allow any attributes, and if so, which? What is the definition of
dc:SimpleLiteral?

Michael Kay
Saxonica

On 20/03/2013 13:03, Dave Pawson wrote:

>      <xs:restriction base="dc:SimpleLiteral">
>          <xs:simpleType> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>            <xs:restriction base="dcmitype:DCMIType"/>
>          </xs:simpleType>
>          <xs:attribute ref="xml:lang" use="prohibited"/>
>      </xs:restriction>
>     </xs:simpleContent>
>    </xs:complexType>
>
>
>
> The report is A complex type with simple content {defined at line 196
> of file:/t...} cannot be derived by restriction from a simple
> type
>
> I've read that ten times and it makes little sense.
>
Well, to understand it you have to know

(a) what is a complex type with simple content? It's what you are trying
to define when you use <xs:simpleContent>; that is, the type of an
element such as <a currency="USD">22.50</a> where the content is
"simple" (here, a number) and there are one or more attributes allowed.

(b) what does it mean to derive by restriction? It means to define one
type as having a value space that is a subset of the value space of some
base type

(c) what is a simple type? It's something defined using xs:simpleType,
in this case dc:SimpleLiteral.

Does that help your understanding?

Michael Kay
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Restriction error

Michael Kay
In reply to this post by Dave Pawson-2
Ignore my previous response. It's probably this bug:

https://saxonica.plan.io/issues/1698

which has been fixed in Saxon 9.4.0.7.

Michael Kay
Saxonica

On 20/03/2013 13:03, Dave Pawson wrote:

> Very new to xsd
>
> Schema part
> <xs:complexType name="DCMIType">
>     <xs:simpleContent>
>      <xs:restriction base="dc:SimpleLiteral">
>          <xs:simpleType> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>            <xs:restriction base="dcmitype:DCMIType"/>
>          </xs:simpleType>
>          <xs:attribute ref="xml:lang" use="prohibited"/>
>      </xs:restriction>
>     </xs:simpleContent>
>    </xs:complexType>
>
> when validating an instance to a schema which includes this block, the arrowed
> line is being pointed out as in error.
> Validating via oXygen 14.2, using saxon
>
>
> The report is A complex type with simple content {defined at line 196
> of file:/t...} cannot be derived by restriction from a simple
> type
>
> I've read that ten times and it makes little sense.
>
> Can anyone suggest a change to the schema snippet to clarify/remove
> the error please?
>
>
> TiA
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Restriction error

Dave Pawson-2
In reply to this post by Michael Kay
Note I'm the real newbie here Mike.

On 20 March 2013 13:53, Michael Kay <[hidden email]> wrote:

> A complex-type-with-simple-content is generally defined by extension: think
> of it as first defining the simple content of the element, then extending it
> to allow attributes.
>
> You can define a c-t-with-s-c as a restriction of another c-t-with-s-c, but
> that doesn't seem to be what you are doing here; the suggestion from the
> error message is that dc:SimpleLiteral is a simple type, not a c-t-with-s-c.
>
> Difficult to correct this without knowing what you are trying to achieve.
> Why are you saying xml:lang is prohibited? Does your new type allow any
> attributes, and if so, which? What is the definition of dc:SimpleLiteral?

I'm trying to understand this schema, then reduce it.

Defn:

<xs:complexType name="SimpleLiteral" mixed="true">
                <xs:annotation>
                        <xs:documentation xml:lang="en">
            This is the default type for all of the DC elements.
            It permits text content only with optional
            xml:lang attribute.
            Text is allowed because mixed="true", but sub-elements
            are disallowed because minOccurs="0" and maxOccurs="0"
            are on the xs:any tag.

       This complexType allows for restriction or extension permitting
            child elements.
    </xs:documentation>
                </xs:annotation>
                <xs:complexContent mixed="true">
                        <xs:restriction base="xs:anyType">
                                <xs:sequence>
                                        <xs:any processContents="lax" minOccurs="0" maxOccurs="0"/>
                                </xs:sequence>
                                <xs:attribute ref="xml:lang" use="optional"/>
                        </xs:restriction>
                </xs:complexContent>
        </xs:complexType>



Is that any help?


regards




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

Reply | Threaded
Open this post in threaded view
|

Redefinition of group, who's correct

Pierre Attar
Hi,

I have a problem using group redefinitions and validating both with
XMLSpy (who complains) and Oxygen (who validates).
My question : who is correct ? Where a I wrong ?

Note: my schema are a lot more complex but I try to make a sample (non
realistic) in order to isolate my question.

Here is the situation :

base.xsd declares a group called essai :
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://modeles.fr/modeles/reference"
targetNamespace="http://modeles.fr/modeles/reference"
elementFormDefault="qualified" attributeFormDefault="unqualified">
     <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
         <xs:annotation>
             <xs:documentation>Comment describing your root
element</xs:documentation>
         </xs:annotation>
     </xs:element>
     <xs:group name="essai">
         <xs:choice/>
     </xs:group>
</xs:schema>


other.xsd only includes base.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://modeles.fr/modeles/reference"
targetNamespace="http://modeles.fr/modeles/reference"
elementFormDefault="qualified" attributeFormDefault="unqualified">
     <xs:include schemaLocation="base.xsd"/>
</xs:schema>


And now, redefine .xsd both redefine base.xsd and includes other.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://modeles.fr/modeles/reference"
targetNamespace="http://modeles.fr/modeles/reference"
elementFormDefault="qualified" attributeFormDefault="unqualified">
     <xs:redefine schemaLocation="base.xsd">
         <xs:group name="essai">
             <xs:choice>
                 <xs:group ref="essai"/>
                 <xs:element name="test"/>
             </xs:choice>
         </xs:group>
     </xs:redefine>
     <xs:include schemaLocation="other.xsd"/>
</xs:schema>


At this time, XML spy complains but not oxygen 14.2. If I remove the
include, no problem found.

Any ideas ?

Pierre


Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

Gerben Abbink
I tried your example in XMLBlueprint using Xerces2 and MSXML6: both XML processors say the schema is valid.

However, in XMLSpy is get this error: "'essai' is already declared in schema document 'redefine.xd'. I don't know why XMLSpy is complaining.

- Gerben Abbink
Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

Michael Kay
In reply to this post by Pierre Attar
Since oXygen allows a choice of schema processors, it would be useful to
say which one you selected (or to try more than one).

It would also be useful to tell us what XMLSpy says is wrong - what is
the error message?

Michael Kay
Saxonica

On 20/03/2013 17:56, Pierre Attar wrote:

> Hi,
>
> I have a problem using group redefinitions and validating both with
> XMLSpy (who complains) and Oxygen (who validates).
> My question : who is correct ? Where a I wrong ?
>
> Note: my schema are a lot more complex but I try to make a sample (non
> realistic) in order to isolate my question.
>
> Here is the situation :
>
> base.xsd declares a group called essai :
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
>         <xs:annotation>
>             <xs:documentation>Comment describing your root
> element</xs:documentation>
>         </xs:annotation>
>     </xs:element>
>     <xs:group name="essai">
>         <xs:choice/>
>     </xs:group>
> </xs:schema>
>
>
> other.xsd only includes base.xsd
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:include schemaLocation="base.xsd"/>
> </xs:schema>
>
>
> And now, redefine .xsd both redefine base.xsd and includes other.xsd
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:redefine schemaLocation="base.xsd">
>         <xs:group name="essai">
>             <xs:choice>
>                 <xs:group ref="essai"/>
>                 <xs:element name="test"/>
>             </xs:choice>
>         </xs:group>
>     </xs:redefine>
>     <xs:include schemaLocation="other.xsd"/>
> </xs:schema>
>
>
> At this time, XML spy complains but not oxygen 14.2. If I remove the
> include, no problem found.
>
> Any ideas ?
>
> Pierre
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

XML4Pharma
XMLSpy has a totally different interpretation of the schema 1.0 spec concerning xs:redefine.
 
I have a had contact with Altova (the developers of XMLSpy) several times and their answer is something like "we are right and the rest of the world is wrong ..."
The CDISC standards make a lot usage of xs:redefine, reason the issue came up in our working group.
So we wrote a "white paper" for the FDA stating that XMLSpy is not a suitable tool for validating CDISC-XML documents.
 
With best regards,
 
Jozef Aerts
XML4Pharma
 
 

> Michael Kay <[hidden email]> hat am 20. März 2013 um 20:05 geschrieben:
>
>
> Since oXygen allows a choice of schema processors, it would be useful to
> say which one you selected (or to try more than one).
>
> It would also be useful to tell us what XMLSpy says is wrong - what is
> the error message?
>
> Michael Kay
> Saxonica
>
> On 20/03/2013 17:56, Pierre Attar wrote:
> > Hi,
> >
> > I have a problem using group redefinitions and validating both with
> > XMLSpy (who complains) and Oxygen (who validates).
> > My question : who is correct ? Where a I wrong ?
> >
> > Note: my schema are a lot more complex but I try to make a sample (non
> > realistic) in order to isolate my question.
> >
> > Here is the situation :
> >
> > base.xsd declares a group called essai :
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
> > <xs:annotation>
> > <xs:documentation>Comment describing your root
> > element</xs:documentation>
> > </xs:annotation>
> > </xs:element>
> > <xs:group name="essai">
> > <xs:choice/>
> > </xs:group>
> > </xs:schema>
> >
> >
> > other.xsd only includes base.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="base.xsd"/>
> > </xs:schema>
> >
> >
> > And now, redefine .xsd both redefine base.xsd and includes other.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:redefine schemaLocation="base.xsd">
> > <xs:group name="essai">
> > <xs:choice>
> > <xs:group ref="essai"/>
> > <xs:element name="test"/>
> > </xs:choice>
> > </xs:group>
> > </xs:redefine>
> > <xs:include schemaLocation="other.xsd"/>
> > </xs:schema>
> >
> >
> > At this time, XML spy complains but not oxygen 14.2. If I remove the
> > include, no problem found.
> >
> > Any ideas ?
> >
> > Pierre
> >
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Redefinition of group, who's correct

Bagepalli, Kiran

Surprised there are people who still use XMLSpy. Are they not a dying breed?

 

From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, March 20, 2013 1:35 PM
To: Michael Kay; [hidden email]
Subject: Re: Redefinition of group, who's correct

 

XMLSpy has a totally different interpretation of the schema 1.0 spec concerning xs:redefine.

 

I have a had contact with Altova (the developers of XMLSpy) several times and their answer is something like "we are right and the rest of the world is wrong ..."

The CDISC standards make a lot usage of xs:redefine, reason the issue came up in our working group.
So we wrote a "white paper" for the FDA stating that XMLSpy is not a suitable tool for validating CDISC-XML documents.

 

With best regards,

 

Jozef Aerts

XML4Pharma

 

 


> Michael Kay <[hidden email]> hat am 20. März 2013 um 20:05 geschrieben:
>
>
> Since oXygen allows a choice of schema processors, it would be useful to
> say which one you selected (or to try more than one).
>
> It would also be useful to tell us what XMLSpy says is wrong - what is
> the error message?
>
> Michael Kay
> Saxonica
>
> On 20/03/2013 17:56, Pierre Attar wrote:
> > Hi,
> >
> > I have a problem using group redefinitions and validating both with
> > XMLSpy (who complains) and Oxygen (who validates).
> > My question : who is correct ? Where a I wrong ?
> >
> > Note: my schema are a lot more complex but I try to make a sample (non
> > realistic) in order to isolate my question.
> >
> > Here is the situation :
> >
> > base.xsd declares a group called essai :
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
> > <xs:annotation>
> > <xs:documentation>Comment describing your root
> > element</xs:documentation>
> > </xs:annotation>
> > </xs:element>
> > <xs:group name="essai">
> > <xs:choice/>
> > </xs:group>
> > </xs:schema>
> >
> >
> > other.xsd only includes base.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="base.xsd"/>
> > </xs:schema>
> >
> >
> > And now, redefine .xsd both redefine base.xsd and includes other.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:redefine schemaLocation="base.xsd">
> > <xs:group name="essai">
> > <xs:choice>
> > <xs:group ref="essai"/>
> > <xs:element name="test"/>
> > </xs:choice>
> > </xs:group>
> > </xs:redefine>
> > <xs:include schemaLocation="other.xsd"/>
> > </xs:schema>
> >
> >
> > At this time, XML spy complains but not oxygen 14.2. If I remove the
> > include, no problem found.
> >
> > Any ideas ?
> >
> > Pierre
> >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

Michael Kay
In reply to this post by XML4Pharma

It has to be said that xs:redefine is underspecified in some respects. However, for this case the rule is fairly clear:

Attribute group definitions and model group definitions must be supersets or subsets of their original definitions, either by including exactly one reference to themselves or by containing only (possibly restricted) components which appear in a corresponding way in their <redefine>d selves.

In other words, a redefined group must be either a restriction or an extension of the original. Or more precisely,

6 Within the [children], for each <group> the appropriate case among the following must be true:
6.1 If it has a <group> among its contents at some level the ·actual value· of whose ref [attribute] is the same as the ·actual value· of its own name attribute plus target namespace, then all of the following must be true:
6.1.1 It must have exactly one such group.
6.1.2 The ·actual value· of both that group's minOccurs and maxOccurs [attribute] must be 1 (or ·absent·).
6.2 If it has no such self-reference, then all of the following must be true:
6.2.1 The ·actual value· of its own name attribute plus target namespace must successfully ·resolve· to a model group definition in I.
6.2.2 The {model group} of the model group definition which corresponds to it per XML Representation of Model Group Definition Schema Components (§3.7.2) must be a ·valid restriction· of the {model group} of that model group definition in I, as defined in Particle Valid (Restriction) (§3.9.6).

This example clearly satisfies 6.1.

In my view, however, it is unwise to rely heavily on xs:redefine. Schemas that use xs:redefine don't compose well with each other: when you combine a schema that uses xs:redefine with another schema, the meaning of the definitions in the second schema can change as a side-effect.

Michael Kay
Saxonica


On 20/03/2013 20:34, [hidden email] wrote:
XMLSpy has a totally different interpretation of the schema 1.0 spec concerning xs:redefine.
 
I have a had contact with Altova (the developers of XMLSpy) several times and their answer is something like "we are right and the rest of the world is wrong ..."
The CDISC standards make a lot usage of xs:redefine, reason the issue came up in our working group.
So we wrote a "white paper" for the FDA stating that XMLSpy is not a suitable tool for validating CDISC-XML documents.
 
With best regards,
 
Jozef Aerts
XML4Pharma
 
 

> Michael Kay [hidden email] hat am 20. März 2013 um 20:05 geschrieben:
>
>
> Since oXygen allows a choice of schema processors, it would be useful to
> say which one you selected (or to try more than one).
>
> It would also be useful to tell us what XMLSpy says is wrong - what is
> the error message?
>
> Michael Kay
> Saxonica
>
> On 20/03/2013 17:56, Pierre Attar wrote:
> > Hi,
> >
> > I have a problem using group redefinitions and validating both with
> > XMLSpy (who complains) and Oxygen (who validates).
> > My question : who is correct ? Where a I wrong ?
> >
> > Note: my schema are a lot more complex but I try to make a sample (non
> > realistic) in order to isolate my question.
> >
> > Here is the situation :
> >
> > base.xsd declares a group called essai :
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
> > <xs:annotation>
> > <xs:documentation>Comment describing your root
> > element</xs:documentation>
> > </xs:annotation>
> > </xs:element>
> > <xs:group name="essai">
> > <xs:choice/>
> > </xs:group>
> > </xs:schema>
> >
> >
> > other.xsd only includes base.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="base.xsd"/>
> > </xs:schema>
> >
> >
> > And now, redefine .xsd both redefine base.xsd and includes other.xsd
> >
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://modeles.fr/modeles/reference"
> > targetNamespace="http://modeles.fr/modeles/reference"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> > <xs:redefine schemaLocation="base.xsd">
> > <xs:group name="essai">
> > <xs:choice>
> > <xs:group ref="essai"/>
> > <xs:element name="test"/>
> > </xs:choice>
> > </xs:group>
> > </xs:redefine>
> > <xs:include schemaLocation="other.xsd"/>
> > </xs:schema>
> >
> >
> > At this time, XML spy complains but not oxygen 14.2. If I remove the
> > include, no problem found.
> >
> > Any ideas ?
> >
> > Pierre
> >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

Pierre Attar
In reply to this post by Pierre Attar
Sorry I did not saw answers to questions because I had a problem with my
mailer.

In Oxygen, I'm using Saxon-EE : No errors.

In XMLSpy, the message is :
The schema doesn't appear to be valid by itself (as a part of another
schema, it might still be OK).
     'essai' is already declared in schema document 'C:\temp\sch\base.xsd'.
         Error location: xs:schema / xs:redefine / xs:group
         Details
             sch-props-correct.2: 'essai' is already declared in schema
document 'C:\temp\sch\base.xsd'.

When trying to write this schema, my assumption was a little bit DTD
like interpretation : the first defininition is the right one.

Pierre

Le 20/03/2013 18:56, Pierre Attar a écrit :

> Hi,
>
> I have a problem using group redefinitions and validating both with
> XMLSpy (who complains) and Oxygen (who validates).
> My question : who is correct ? Where a I wrong ?
>
> Note: my schema are a lot more complex but I try to make a sample (non
> realistic) in order to isolate my question.
>
> Here is the situation :
>
> base.xsd declares a group called essai :
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:element name="ENTER_NAME_OF_ROOT_ELEMENT_HERE">
>         <xs:annotation>
>             <xs:documentation>Comment describing your root
> element</xs:documentation>
>         </xs:annotation>
>     </xs:element>
>     <xs:group name="essai">
>         <xs:choice/>
>     </xs:group>
> </xs:schema>
>
>
> other.xsd only includes base.xsd
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:include schemaLocation="base.xsd"/>
> </xs:schema>
>
>
> And now, redefine .xsd both redefine base.xsd and includes other.xsd
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns="http://modeles.fr/modeles/reference"
> targetNamespace="http://modeles.fr/modeles/reference"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>     <xs:redefine schemaLocation="base.xsd">
>         <xs:group name="essai">
>             <xs:choice>
>                 <xs:group ref="essai"/>
>                 <xs:element name="test"/>
>             </xs:choice>
>         </xs:group>
>     </xs:redefine>
>     <xs:include schemaLocation="other.xsd"/>
> </xs:schema>
>
>
> At this time, XML spy complains but not oxygen 14.2. If I remove the
> include, no problem found.
>
> Any ideas ?
>
> Pierre
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Redefinition of group, who's correct

C. M. Sperberg-McQueen-2
In reply to this post by Pierre Attar

On Mar 20, 2013, at 11:56 AM, Pierre Attar wrote:

> Hi,
>
> I have a problem using group redefinitions and validating both with XMLSpy (who complains) and Oxygen (who validates).
> My question : who is correct ? Where a I wrong ?
>
> Note: my schema are a lot more complex but I try to make a sample (non realistic) in order to isolate my question.
>
> Here is the situation :
>
> base.xsd declares a group called essai :
> ...
>
>
> other.xsd only includes base.xsd
> ...
> And now, redefine .xsd both redefine base.xsd and includes other.xsd
>
> ...
> At this time, XML spy complains but not oxygen 14.2. If I remove the include, no problem found.

The upshot is that in the schema described by redefine.xsd, the components
declared in base.xsd are both redefined (via the redefinition of base.xsd)
and included as-is (via the inclusion of other.xsd and the inclusion, there,
of base.xsd).

Such situations do not, I believe, have any non-contradictory interpretation
in the XSD spec, and (as one might expect under the circumstances)
processors differ in how they attempt to make sense of the contradictory
rules in the spec.

The description of xs:redefine says (simplifying slightly) that the redefined
version of the essai element should be included in the schema.  The
description of xs:include says (again simplifying) that the unmodified version
of the 'essai' element should be included in the schema.  

If both of these descriptions are taken at face value, then the schema described
by redefine.xsd has two top-level declarations for 'essai' and does not conform
to the spec.  That appears to be the reading adopted by XML Spy.

The spec also says in passing (and without any concrete explanation of what
is meant) that redefinition has "a pervasive impact".  This is taken by some
implementations to mean that the inclusion of base.xsd should essentially
be ignored (or else be regarded as covered by the redefinition request).
That appears to be the reading adopted by Xerces and/or Saxon, which
Oxygen is using.

Of the two readings of the spec, the second one (which allows this schema
to be legal) is probably closer to what the designers of the redefine
construct wanted to achieve, and most users probably find it more useful.
But the first reading seems to me to be a perfectly plausible -- in fact,
somewhat more plausible -- reading of what the spec actually says about
the meaning of the constructs involved.

Both readings seem to involve ignoring parts of the spec:  the first reading
ignores the sentence about redefinition having pervasive impact as being
unclear or meaningless, or else must assign it some meaning compatible
with the rest of the reading.   The second reading ignores all the rules in
section 4 of the spec about the meaning of xs:include.  

To answer your questions directly:

Who is correct?   The spec is too badly drafted to allow this question to have
a clear answer.  So:  no one is correct, or everyone is correct.  For all
practical purposes, we must act as if the spec said explicitly that the
behavior of conforming processors in cases like this one were
implementation-dependent.

Where are you going wrong?  You are going wrong by including
constructs in your schemas whose meaning is implementation-dependent
(in this case because the meaning is not well defined by the XSD
spec), and then expecting different processors to behave consistently.
If you want consistent behavior across processors, eliminate the
double reference to base.xsd.  

The simplest way to avoid implementation-dependent processing
of include, import, and redefine is to remove all instances of xs:include,
xs:override, and xs:redefine, and all instances of @schemaLocation
on xs:import, from any schema document that actually declares
anything (elements, attributes, types, ...), and move them into
distinct 'driver' documents which contain no declarations of their
own, but only references to other schema documents:

In the ideal case:

  - "class 1" schema documents contain declarations and definitions;
    if they have xs:import elements, those elements have no
    schemaLocation attributes.

  - "class 2" schema documents contain nothing but a top-level
    xs:override or xs:redefine pointing to a class-1 schema
    document.

  - "class 3" schema documents contain nothing but xs:include
    (and possibly xs:import) elements pointing to class-1 or class-2
    documents. If xs:import elements are present, they may carry
    schemaLocation attributes.

In complex cases, you may end up with a class-2 document
needing to redefine the entire set of components for a namespace,
so it may end up pointing to a class-3 and not a class-1 document.

In any case, avoid multiple references to the same schema
document and avoid cyclic references (A refers to B refers to
C refers to ... refers to A):  they have interoperability problems
out of all proportion to their convenience.
 

--
****************************************************************
* 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: Redefinition of group, who's correct

C. M. Sperberg-McQueen-2
In reply to this post by Pierre Attar

On Mar 25, 2013, at 2:49 AM, Pierre Attar wrote:

>
>
> When trying to write this schema, my assumption was a little bit DTD like interpretation : the first defininition is the right one.


That's true for entity and attribute declarations in DTDs, but not for
element declarations (which lead to errors when duplicated) or
attribute-list declarations (which accumulate).

An idea very similar to your operating assumption was in fact
proposed (a sort of schema-component search path), but I am
ashamed to relate that it was not taken very seriously and
was not adopted.  The XSD rules for include and import might
have been much easier to understand (and thus easier to write
without contradictions) has the WG adopted it.  But the
majority of the WG thought that it would be too error-prone.

--
****************************************************************
* 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: Restriction error

C. M. Sperberg-McQueen-2
In reply to this post by Dave Pawson-2

On Mar 20, 2013, at 8:06 AM, Dave Pawson wrote:

> Note I'm the real newbie here Mike.
>
> On 20 March 2013 13:53, Michael Kay <[hidden email]> wrote:
>> A complex-type-with-simple-content is generally defined by extension: think
>> of it as first defining the simple content of the element, then extending it
>> to allow attributes.
>>
>> You can define a c-t-with-s-c as a restriction of another c-t-with-s-c, but
>> that doesn't seem to be what you are doing here; the suggestion from the
>> error message is that dc:SimpleLiteral is a simple type, not a c-t-with-s-c.
>>
>> Difficult to correct this without knowing what you are trying to achieve.
>> Why are you saying xml:lang is prohibited? Does your new type allow any
>> attributes, and if so, which? What is the definition of dc:SimpleLiteral?
>
> I'm trying to understand this schema, then reduce it.
>
> Defn:
>
> <xs:complexType name="SimpleLiteral" mixed="true">
> ...
> </xs:complexType>
>
>
>
> Is that any help?

Yes, it is.  If I understand correctly, you would like to define
a restricted form of the XML vocabulary defined at
http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
in which elements are not allowed the use of xml:lang, and
you would like to do so without just copying all the schema
documents and modifying them.

If you have access to an XSD 1.1 processor, your best bet
is probably to use xsd:override to change the declaration of
dc:SimpleLiteral.  Otherwise, you will need to use xsd:redefine.
Both of these constructs are intended (sometimes among
other things) for the use case of local restrictions to a
public schema.

Your redefinition of the dc: namespace can look like this:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://purl.org/dc/elements/1.1/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  elementFormDefault="qualified">
 
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>

  <xs:redefine schemaLocation="http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd">
    <xs:complexType name="SimpleLiteral">
     
      <xs:annotation>
        <xs:documentation xml:lang="en">
          This is a restriction of the default type for all of the DC elements.
          It permits text content only with no xml:lang attribute.  (That is
          its difference from the standard schema at
          http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
         
          Text is allowed because mixed="true", but sub-elements
          are disallowed because minOccurs="0" and maxOccurs="0"
          are on the xs:any tag.
         
          This complexType allows for restriction or extension permitting
          child elements.
        </xs:documentation>
      </xs:annotation>
     
      <xs:complexContent mixed="true">
        <xs:restriction base="dc:SimpleLiteral">
          <xs:sequence/>
          <xs:attribute ref="xml:lang" use="prohibited"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:redefine>
</xs:schema>

I hope this helps.

Michael Sperberg-McQueen


--
****************************************************************
* 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: Restriction error

Dave Pawson-2
Thanks Michael.
I am using a 1.0 schema, but if you see the later post,
I think this is one that MK noted as a bug in his validator
as used in oXygen.

regards

On 1 April 2013 00:25, C. M. Sperberg-McQueen <[hidden email]> wrote:

>
> On Mar 20, 2013, at 8:06 AM, Dave Pawson wrote:
>
>> Note I'm the real newbie here Mike.
>>
>> On 20 March 2013 13:53, Michael Kay <[hidden email]> wrote:
>>> A complex-type-with-simple-content is generally defined by extension: think
>>> of it as first defining the simple content of the element, then extending it
>>> to allow attributes.
>>>
>>> You can define a c-t-with-s-c as a restriction of another c-t-with-s-c, but
>>> that doesn't seem to be what you are doing here; the suggestion from the
>>> error message is that dc:SimpleLiteral is a simple type, not a c-t-with-s-c.
>>>
>>> Difficult to correct this without knowing what you are trying to achieve.
>>> Why are you saying xml:lang is prohibited? Does your new type allow any
>>> attributes, and if so, which? What is the definition of dc:SimpleLiteral?
>>
>> I'm trying to understand this schema, then reduce it.
>>
>> Defn:
>>
>> <xs:complexType name="SimpleLiteral" mixed="true">
>>               ...
>>       </xs:complexType>
>>
>>
>>
>> Is that any help?
>
> Yes, it is.  If I understand correctly, you would like to define
> a restricted form of the XML vocabulary defined at
> http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
> in which elements are not allowed the use of xml:lang, and
> you would like to do so without just copying all the schema
> documents and modifying them.
>
> If you have access to an XSD 1.1 processor, your best bet
> is probably to use xsd:override to change the declaration of
> dc:SimpleLiteral.  Otherwise, you will need to use xsd:redefine.
> Both of these constructs are intended (sometimes among
> other things) for the use case of local restrictions to a
> public schema.
>
> Your redefinition of the dc: namespace can look like this:
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>   targetNamespace="http://purl.org/dc/elements/1.1/"
>   xmlns:dc="http://purl.org/dc/elements/1.1/"
>   elementFormDefault="qualified">
>
>   <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
>
>   <xs:redefine schemaLocation="http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd">
>     <xs:complexType name="SimpleLiteral">
>
>       <xs:annotation>
>         <xs:documentation xml:lang="en">
>           This is a restriction of the default type for all of the DC elements.
>           It permits text content only with no xml:lang attribute.  (That is
>           its difference from the standard schema at
>           http://dublincore.org/schemas/xmls/qdc/2008/02/11/dc.xsd
>
>           Text is allowed because mixed="true", but sub-elements
>           are disallowed because minOccurs="0" and maxOccurs="0"
>           are on the xs:any tag.
>
>           This complexType allows for restriction or extension permitting
>           child elements.
>         </xs:documentation>
>       </xs:annotation>
>
>       <xs:complexContent mixed="true">
>         <xs:restriction base="dc:SimpleLiteral">
>           <xs:sequence/>
>           <xs:attribute ref="xml:lang" use="prohibited"/>
>         </xs:restriction>
>       </xs:complexContent>
>     </xs:complexType>
>   </xs:redefine>
> </xs:schema>
>
> I hope this helps.
>
> Michael Sperberg-McQueen
>
>
> --
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com
> * http://cmsmcq.com/mib
> * http://balisage.net
> ****************************************************************
>
>
>
>



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