Re: 2.1 a-d: Link Recognition by Reserved Attribute?
Eve L. Maler wrote:
> At 07:24 PM 2/13/97 -0600, len bullard wrote:
> >has anyone considered what happens when several arch forms
> >must be applied to the same element type? For example,
> >a community wants to use the XML type for a link, but
> >specialize it further with arch forms only a set
> >particular to a community shares?
> We've discussed it a bit in Davenport. One idea was to add an empty
> placeholder parameter entity called something like "morph.elemname.attrib"
> to each ATTLIST, so that you could provide different modules containing
> non-empty morph.xxx.attrib definitions that map your elements to different
> AFs. You'd especially need this where LINK isn't available, but some of
> us found it an appealing idea regardless. (We decided not to adopt it for
Something like this is wanted. We used the hytime method in MID with
the fixed attribute to simply point out to the architecture. In simpler
SGML terms, that works out to be a parameter entity a la MIL-PRF-87269.
It seems we should provide a recommended method. In practice, as
Tim Bray points out, the minimalist position is a tag bag (sort
of the data dictionary or tag registry concept). AFs appear to
bridge the class(oop)/element type distinctions. That is, it
is possible to have several levels of inheritance. My question is,
if none of these levels contribute values (e.g., abstract), then
is is necessary to define them, or to get behavioral interoperability,
is it only necessary (say via the PI) to indicate that this is
what is needed, in effect saying, these are the architectures/classes
that should be supported?
I'm unclear what requirements we are trying to meet. A class enables
inheritance of data types and behaviors. If we use the PI plus
element markers (attributes will be better I think), then we can
define behavior axiomatically and ensure that the XML element types
only define exposed public property values.
Make sense? Sitting here with a dreadful cold and medicated, so...