Re: Codelists: restricting simpleContent complexTypes

Hi Jeni,

puh, that's quite complicated. From an implementation perspective I prefer
to have prohibited attributes explicit and to pass them through to derived
types. But (how I learned today): the type in prohibited attribute declarations
may (must?) be missing.

Here pops up my next question. Is a type definition in an attribute
declaration with use="prohibited" simply ignored, is it an error, or is it validated
to be a subtype? Studying the spec. I found no hint that it is forbidden to
have a type attribute or an inlined type definition for "prohibited"
declarations.

--Stefan

PS: I have my fingers on the code. Maybe this topic could be settled once
for all.

> 
> Hi Stefan,
> 
> > PS: Is it allowed to first prohibit an attribute and to introduce it
> > again later? The spec. says that attribute declarations with
> > use="prohibited" are nothing at all. This suggests that a type does
> > not know if an attribute is prohibited or simply not present.
> > Therefore adding an attribute after it was prohibited should be
> > allowed. Sounds strange, doesn't it?
> 
> Well, I *think* that you're not allowed to add back a prohibited
> attribute. Clause 1.5 of Schema Component Constraint: Derivation Valid
> (Extension) [1] says:
> 
>   1.5 It must in principle be possible to derive the complex type
>       definition in two steps, the first an extension and the second a
>       restriction (possibly vacuous), from that type definition among
>       its ancestors whose {base type definition} is the ·ur-type
>       definition·.
> 
>       NOTE: This requirement ensures that nothing removed by a
>       restriction is subsequently added back by an extension. It is
>       trivial to check if the extension in question is the only
>       extension in its derivation, or if there are no restrictions bar
>       the first from the ·ur-type definition·.
> 
> The NOTE implies that you shouldn't be able to prohibit an attribute
> and then introduce it again later, but I've never been able to work
> out how the clause actually guarantees that. For example, if I did:
> 
> <xs:complexType name="T1">
>   <xs:sequence />
> </xs:complexType>
> 
> <xs:complexType name="T2">
>   <xs:extension base="T1">
>     <xs:attribute name="foo" />
>   </xs:extension>
> </xs:complexType>
> 
> <xs:complexType name="T3">
>   <xs:restriction base="T2">
>     <xs:attribute name="foo" use="prohibited" />
>   </xs:restriction>
> </xs:complexType>
> 
> <xs:complexType name="T4">
>   <xs:extension base="T3">
>     <xs:attribute name="foo" />
>   </xs:extension>
> </xs:complexType>
> 
> then I can derive T4 in two steps from T1 (the type amongst T4's
> ancestors whose base type definition is the ur-type definition), first
> an extension:
> 
> <xs:complexType name="_T4">
>   <xs:extension base="T1">
>     <xs:attribute name="foo" />
>   </xs:extension>
> </xs:complexType>
> 
> and then a restriction:
> 
> <xs:complexType name="T4">
>   <xs:restriction base="_T4" />
> </xs:complexType>
> 
> I think that the intention is that the intermediate type definition is
> constructed according to the instructions:
> 
>   Constructing the intermediate type definition to check this
>   constraint is straightforward: simply re-order the derivation to put
>   all the extension steps first, then collapse them into a single
>   extension. If the resulting definition can be the basis for a valid
>   restriction to the desired definition, the constraint is satisfied.
> 
> in which case the intermediate definition would be:
> 
> <xs:complexType name="_T4">
>   <xs:extension base="T1">
>     <xs:attribute name="foo" />
>     <xs:attribute name="foo" />
>   </xs:extension>
> </xs:complexType>
> 
> which wouldn't be allowed because it has two attribute uses for the
> same attribute, and which would therefore mean that T4 wasn't a valid
> extension of T3.
> 
> Cheers,
> 
> Jeni
> 
> [1] http://www.w3.org/TR/xmlschema-1/#cos-ct-extends
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Wednesday, 16 October 2002 09:19:48 UTC