Hi Erik--
That's right - I do vaguely remember Bruce Esrig proposing something
like this. Is he still on the TC?
As for the issues you raise:
- We could just make it a rule that arbitrary
attributes can only be considered renamings of the unspecialized data
element. After all, this mechanism is really just a way to preserve
them during generalization/respecialization. Or they could be renamed
from specialized data elements - provided the renaming resolution
happens before generalization, and after respecialization.
- We could just say that arbitrary attributes
are allowed only on elements that can contain the data element - or
that can be referred to by a data-about element. I think that would
handle most if not every case where implementers might want them -
certainly more than the 80/20 rule would mandate.
Hope this helps!
--Dana
Erik Hennum wrote:
Hi, Dana:
Interesting. I hadn't made the connection between element aliasing and
<data>-to-attribute mutability (for which Bruce Esrig was one
proponent, if I recall). I can certainly see the conceptual benefits
you point out of having a single fundamental story and the convenience
for generalization.
One issue would be how runtime processors of documents get access to
the type inheritance information about an attribute specialized from
<data> (or, maybe better, from a <data> specialization that
has no content). If DITA continues to use architectural attributes,
there would have to be an architectural attribute (maybe on the
<topic> element?) that declares the ancestry of the added
attribute.
Another issue would be that <data> or the base element for
specialized attributes would have to be available everywhere.
Something to mull...
Thanks,
Erik Hennum
ehennum@us.ibm.com
Dana
Spradley <dana.spradley@oracle.com>
...
And I think it might also be the most appropriate place to handle the
long-deferred project to allow adding implementation-specific metadata
attributes to arbitrary elements.
Such attributes could be considered renamings of contained data or
associated data-about elements whose name attribute has the same name
as the implementation-specific attribute's name.
This makes more sense to me than evolving a
specialization/generalization mechanism for such attributes, given that
data elements, like implementation-specific attributes, have no generic
processing.
|