complexType derivation by extension & simpleType

[Jean-Louis Vila <jl...@cosmosbay.com>]

Just a remark,

   Theorically, we can derive a complexType with a simpleType base.
   --Ok, This allows to get a simpleType with attribute.

   But, WD-part 1/§5.11-"constraint on Schemas:Deriavtion valid (Extension)"
   says "1.2 - If the {base...} is a simple type definition, the {content..}
   must be the same simple type definition"

   This is an important point to avoid use of :
       <complexType base="xsd:string" derivedBy="extension" content="mixed">
       wich is incoherent in the instance.
    So you must write :
        <complexType base="xsd:string" derivedBy="extension"
content="xsd:string">
    But the pb is that content is a NMTOKEN
(empty|elementOnly|textOnly|mixed)!!!

The conclusion is that today we cannot validate a schema with complexType
base upon a simpleType !

I'm interested in your opinion about this point in the final recommandation.

Jean-Louis Vila

RE: complexType derivation by extension & simpleType

[Jean-Louis Vila <jl...@cosmosbay.com>]

Hi Eric,

>
> >
> >    This is an important point to avoid use of :
> >        <complexType base="xsd:string" derivedBy="extension"
> content="mixed">
>
> According to the spec, this would not be a valid compelxType definition,
> please refer to Section 4.3.3, "Schema Representation Constraint: Complex
> Type Representation OK. 1.2.  so in this case, the only
> reasonable value for
> content attribute would be "textOnly", though the spec doesn't explicitly
> say that.


It's not directly my purpose. My reflection is only about derivation
by extension with base="<aSimpleType>". If you read §5.11, the Derivation
Valid (Extension), jump to 1.2 point, you'll read this :
   "If a {base type definition} is a simple type definition, the {content
type}
must be the SAME SIMPLE TYPE definition"....

Here , the subject of my reflection !!!


>
> >        wich is incoherent in the instance.
> >     So you must write :
> >         <complexType base="xsd:string" derivedBy="extension"
> > content="xsd:string">
> >     But the pb is that content is a NMTOKEN
> > (empty|elementOnly|textOnly|mixed)!!!
> >
>
> that is right.
>
> > The conclusion is that today we cannot validate a schema with
> complexType
> > base upon a simpleType !
> >
>
> Yes, we can.
> when a complexType is derived directly from a simpleType, several rules
> needs to be followed based on the spec:
> - "derivedBy" must be "extension"
> - the "extenstion" could only be adding attributes or attirutes
> wildcards to
> the baseType.
> - after such a complexType is defined, its {content type} property will
> still be resolved to be a simpeType.

You're right only if you rewrite your own validation parser, but with Xerces
and others tools (spy, extensibility .....), derivation base on simpleType
could not be validate !

Regards,
Jean-Louis Vila

Re: complexType derivation by extension & simpleType

[Eric Ye <er...@locus.apache.org>]

>
>    This is an important point to avoid use of :
>        <complexType base="xsd:string" derivedBy="extension"
content="mixed">

According to the spec, this would not be a valid compelxType definition,
please refer to Section 4.3.3, "Schema Representation Constraint: Complex
Type Representation OK. 1.2.  so in this case, the only reasonable value for
content attribute would be "textOnly", though the spec doesn't explicitly
say that.

>        wich is incoherent in the instance.
>     So you must write :
>         <complexType base="xsd:string" derivedBy="extension"
> content="xsd:string">
>     But the pb is that content is a NMTOKEN
> (empty|elementOnly|textOnly|mixed)!!!
>

that is right.

> The conclusion is that today we cannot validate a schema with complexType
> base upon a simpleType !
>

Yes, we can.
when a complexType is derived directly from a simpleType, several rules
needs to be followed based on the spec:
- "derivedBy" must be "extension"
- the "extenstion" could only be adding attributes or attirutes wildcards to
the baseType.
- after such a complexType is defined, its {content type} property will
still be resolved to be a simpeType.


_____


Eric Ye * IBM, JTC - Silicon Valley * ericye@locus.apache.org