Re: questions about attribute declarations

At 07:33 PM 9/23/96 CDT, Michael Sperberg-McQueen wrote:
>Questions about attribute declarations I'd like to see discussed while
>the voting booth is still open:
>
>*  Should XML retain SGML's prohibition on multiple attribute-list
>declarations for the same element (11.3.1) or on multiple declarations
>for the same attribute (11.3.2)?

While I like having multiple attribute list declarations for the same
element type, I think that we should not do it for XML, only because it
removes one more thing that would have to be mangled to go from XML to SGML.

>* Should XML change the set of types available for attributes?
>E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and
>adding constraints in the form of regular expressions, ISO dates,
>language-code, external-id, typed IDREF, ... (7.9.4, 11.3.3)

I'm not sure what the value of suppressing the listed types is. I don't see
that they add significant complexity and they are useful.

The only way we could do lexical type constraints would be to do what
HyTime does with Lextype, otherwise we break SGML.  The HyTime lextype
mechanism lets you use any expression language you want, but we'd still
have to define one or pick one.  Seems like a big can of worms that would
only complicate validation.

>* Should XML remove SGML's prohibition on multiple ID or NOTATION
>attributes on the same element (11.3.3)?

I could see an argument for having multiple IDs for a single element
(different names used in different domains), although I'm hard pressed to
see this as so compelling that we would accept the cost of incompatibility
(when translating to SGML, which ID attribute would you use?).

For notations, it normally seems meaningless to consider the content of an
element to be in more than one notation at the same time, but I could see
that there might be times where this is the case.  But again, it doesn't
seem compelling relative to the cost of incompatibility.

These are certainly good issues for the SGML revision, though. 

>* Should XML allow more than one enumerated type (name-group declared
>value) to contain the same possible value (11.3.3)?

If we don't allow shorttag, then I don't see a problem here because the
attribute can always be redeclared as "NAMES" with a corresponding lexical
model, so there's not a serious compatibility issue.

>* Should XML define new specific methods of inferring values for
>attributes with no attribute-value specifications (11.3.4)?  E.g.
>INHERITED, to signify that the value is taken from the attribute of the
>same name (and type) on the smallest enclosing element with such an
>attribute.

No. There are too many possible variations in how you might want
inheritance to work. To make this complete, you need a way to say, for each
attribute of each element type, what the precise inheritance rules are,
something like HyTime's default value list.  Unless we want to accept
default value list, I think such a mechanism is beyond the scope of XML.
It's something we should definitely think about for the SGML revision, though.

Given that DTD-less parsing means you don't know which attributes are
#IMPLIED, it seems like the potential for unintended side effects is very
high if you do define an inheritance rule or rules.

Having said that, it might be useful to define some conventional attribute
form names that have defined inheritance rules, e.g. "language".  Having
conventional attribute names would require some sort of renaming mechanism
such as the "HyNames" mechanism used in HyTime and formalized as the
"ArcNamrA" attribute in architectures (see
http://www.jclark.com/sp/archform.htm for a brief description of the
architecture control attributes).

>* When given an incomplete DTD, should XML parsers assume all attributes
>are implicity declared CDATA, or should some attribute names cause other
>assumptions (e.g. attributes with the same name as some type of declared
>value might be assumed to have that declared value)?

While Martin Bryan doesn't like it, I think it's reasonable to define a set
of conventional attribute names: ID, ENTITY, NOTATION, IDREF(S).  Behaves
the way most people would expect them to behave and removes the need to
declare the attributes in these cases. Doesn't prevent declaring attributes
with other names but does prevent using these attribute names for something
other than their conventional interpretation.  A renaming mechanism could
be used to map your own names to these conventional names, e.g.:

<MyXMLEelement name=foo XMLNames="ID name">

When there's a DTD, the XMLNames (the "architecture renaming attribute")
could be fixed, but when there's no DTD, you'd have to specify it. (Which
raises the posibility that a careless author could do something different
on two different elements:

<MyXMLEelement name=foo XMLNames="ID name">
<MyXMLEelement uniqueID=foo XMLNames="ID uniqueID">

Ugh. Would probably have to make it a reportable XML error to map the same
conventional attribute name to different instance names in the same document.)

Cheers,

E.
--
W. Eliot Kimber (kimber@passage.com) 
Senior SGML Consultant and HyTime Specialist
Passage Systems, Inc., (512)339-1400
10596 N. Tantau Ave., Cupertino, CA 95014-3535 (408) 366-0300, (408)
366-0320 (fax)
2608 Pinewood Terrace, Austin, TX 78757 (512) 339-1400 (fone/fax)
http://www.passage.com (work) http://www.drmacro.com (home)
"If I never had existed, would you still remember me?..."
                                   --Austin Lounge Lizards, "1984 Blues"

Received on Monday, 23 September 1996 23:51:57 UTC