W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2004

RE: can an attribute prohibited by restriction be added back through a subsequent extension?

From: Alessandro Triglia <sandro@mclink.it>
Date: Thu, 22 Jan 2004 12:17:55 -0500
To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, <holstege@mathling.com>
Cc: "'Dare Obasanjo'" <dareo@microsoft.com>, <xmlschema-dev@w3.org>, <www-xml-schema-comments@w3.org>
Message-ID: <003b01c3e10b$b173ec00$7d01a8c0@aldebaran>



> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Henry S. Thompson
> Sent: Thursday, January 22, 2004 08:56
> To: holstege@mathling.com
> Cc: Dare Obasanjo; xmlschema-dev@w3.org; 
> www-xml-schema-comments@w3.org
> Subject: Re: can an attribute prohibited by restriction be 
> added back through a subsequent extension?
> 
> 
> 
> The REC says in clause 1.5 of Schema Component Constraint: 
> Derivation Valid (Extension) [1]:
> 
>  Note: This requirement ensures that nothing removed by a 
> restriction  is subsequently added back by an extension.
> 
> That (rather than clause 1.2 as I think Mary was suggesting) 
> is where the REC tries to answer "no" to the question of 
> "whether an attribute [or element] removed by restriction 
> could be added back in an extension."  However the constraint 
> itself, in my view, fails to achieve this, so processors 
> which allow it are not broken.
> 
> I think we should fix this one way or another -- what do you think is
> best:
> 
>   1) No constraint on re-introduction;
>   2) No re-introduction of any kind (apparent intention of 
> current REC);
>   3) Re-introduction of unchanged originals only (what the current REC
>      actually says)?


I don't see any good reason for forbidding re-introduction.  What was the
rationale?

Allowing the re-introduced attribute-use to have different properties from
the original attribute-use depends on whether the new attribute use is
considered to be "the same" as the original one or another component with
the same name.

Since restriction types do not retain components for "prohibited" attributes
(there is no such thing as a "prohibited attribute-use"), one could say that
the restriction "forgets" the old attribute-use, and therefore there is no
good reason why a subsequent extension should not be allowed to add an
attribute with the same name but different properties.

I noticed that something similar happens with element declarations.

Suppose that a base type has a local element declaration particle E with
some properties, with min occurs 0 and max occurs 1.  A restriction kills
this particle.  A subsequent extension adds a local element declaration
particle with the same name (E) but a different type definition, to the end
of the content.  I don't believe this is forbidden - it *would* be forbidden
if the original particle E were still present, because we would then have
two distinct local element declarations with the same name but different
types in the symbol space of the complex type.  But since the first particle
was not inherited by the restriction, the two particles "E" (introduced at
different steps of the derivation hierarchy) never coexist in the same type.

If the above is true (and we allow the two particles "E" to have different
types on the grounds that they never coexist in the same type), do we really
need to be more restrictive for attributes?

Alessandro Triglia
OSS Nokalva



> 
> ht
> 
> [1] http://www.w3.org/TR/xmlschema-1/#cos-ct-extends
> -- 
>  Henry S. Thompson, HCRC Language Technology Group, 
> University of Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
> 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without 
> it is forged spam]
> 
> 
Received on Thursday, 22 January 2004 12:23:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:41 GMT