[wg11] Part 11: redeclared attributes

[Ed Barkmeyer]

Phil Spiby wrote:

> Both are legal, beyond that it is a matter of taste and clarification for
> the reader.
> 
> If in entity C we used:
> SELF\B.attribute_a : Z; 
> 
> Then it is clearer (at least for me!) that Z must be a specialisation of Y,
> which itself must be a specialisation of X.
> 
> Now if Y and Z are both subtypes of X and related by ANDOR, then the above
> statement would be wrong!, since Z is not a specialisation of Y!
> However, if in entity C we used:
> SELF\A.attribute_a : Z;
> 
> Then we get into the interesting situation, both redeclarations are valid,
> but because C is a subtype of B, both redeclarations must apply, therefore
> instances of C MUST use complex instances of X&Y&Z.

For the record, I agree with Phil.
Of course, I also believe that this fits into the category of things 
that satisfies the Goedel Principle for Language Design:
"You can't get everything you want without allowing things you don't want!"

But Jochen answered Heidi's original question:
In C,
  SELF\A.attribute_a : Z;
is valid, iff Z is a subtype/specialization of X.

On a side note, Georgi Kuzmanov observed:

> On a separate note, I think attribute renaming in e2 may have been
> mis-named and "attribute aliasing" would be a more accurate description
> -  according to e2 9.2.3.4 NOTE 1 "The old identifier remains available
> in this entity data type and in any subtypes that are declared for this
> entity data type".

I had never noticed this Note in 9.2.3.4.

First, this Note does not clearly follow from the normative text.  In 
fact, one might reasonably conclude exactly the opposite from reading 
the text, which uses the terms "different name" and "new identifier" (in 
rule f), rather than "additional" name/identifier.  I don't think this 
can be a Note.

Second, Rule (b) (which is unchanged in edition 2) is now ambiguous. 
"The name of the attribute" does not uniquely identify the object whose 
syntax is being prescribed by rule (b), since the attribute has more 
than one name.  Since the intent of rule (b) appears to be only to 
restate the syntax rule, the appropriate change is to delete it.

Third, and important immediately to Heidi:  In Part 28, the intent of 
the Note in 9.2.3.4 is not supported by the derived XML schema at all! 
In the derived XML schema, when I rename the attribute, I lose the 
original declaration altogether.  So, in the subtype, only one name is 
available for XML use.   Per the N229 CD, the original name is lost, and 
the RENAMED identifier is used in the subtype and its descendents. 
Exception:  if a subtype of the renaming subtype explicitly creates a 
"diamond inheritance", N229 seems to require that the renaming be lost 
in that subtype and its descendents.  Example:

ENTITY A;
  attribute_a: T;
END_ENTITY;

ENTITY B SUBTYPE OF (A);
  SELF\A.attribute_a : T1 RENAMED attr;
END_ENTITY;

ENTITY C SUBTYPE OF (A);
  SELF\A.attribute_a : T2;
END_ENTITY;

ENTITY D SUBTYPE OF (B,C);
  ...
END_ENTITY;

In D (and any subtype of D) is the attribute called "attribute_a" or 
"attr"?  The NOTE in 9.2.3.4 says that in EXPRESS the answer is 
"either".  But in XML schema, I have to choose one.  Part 28 (N229) says 
that in B and its subtypes, the name is "attr", but in C and its 
subtypes the name is "attribute_a".  But then it says that if D has two 
inheritance paths with redeclarations of the same attribute, you use the 
original declaration (in A), because otherwise the preprocessor would 
have to determine what EXPRESS data type (if any) represents the 
intersection of the T1 and T2 subdomains of T.  So the XML version of 
"attribute_a"/"attr" is called "Attribute_a" in D.

But as I read it, N229 implies that if you remove the redeclaration of 
"attribute_a" in the definition of C, then the XML version of 
"attribute_a"/"attr" is called "Attr" in D.  That is, the exception only 
applies if C also redeclares the attribute.

In Georgi's terms, the XML Schema language does not support "aliasing" 
per se.  What it does support is "substitution", and for the (default) 
"accessor element" mapping, we could implement the intent of the Note 
via an XML "substitution group" (maybe, I'm not sure whether this can be 
done with "context names" in XML).  But for the "accessor attribute" 
(OSEB-style) mapping, there is no XML schema equivalent -- it can't be done.

Further observation: In N229, for the accessor attribute case, I think 
we currently get *two* attributes: one named Attribute_a with data type 
T (mapped to XML), and the other named Attr with data type T1, because 
we don't explicitly include the inherited XML attribute with 
use="prohibited" (so we implicitly inherit it with use="required" or 
whatever the original declaration contained).  If so, this is a bug -- 
this problem already occurs in B, and has nothing to do with "diamond 
inheritance".

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."