GI vs. Element Type (Was: RE: JUMBO)

[Russ Chamberlain]

Hello XMLers,

> lee at sq.com wrote:
>> > Peter Murray-Rust wrote:
>> I still don't know if there is a difference between 'GI' and 
>> 'Element type', for example.
>
>In XML they are the same, as far as I can tell.
>
>The detailed reasoning follows, but you can ignore it if you like....
>
>Lee
>
>*
>
>An element type can be a generic identifier, a name group,
>a ranked element or a ranked group. [117; p. 406 of the SGML Handbook]
>
>We don't have RANK in XML, so
>An element type can be a generic identifier or a name group.
>
>For example,
><!Element (boy|girl) (%child;)>
>in SGML defines the content for both boy and girl.
>
>This is (I think) not allowed in XML, so in XML there is no practical
>difference between a GI and an element type.

Not quite true. You can achieve the identical effect with the following:

    <!Element boy (%child;)>
    <!Element girl (%child;)>

Here's the verbatim definitions from my ISO 8879 spec:

    4.114 element type: A class of elements having similar
    characteristics; for example, paragraph, chapter, abstract, footnote,
    or bibliography.

    4.145 generic identifier: A name that identifies the element type
    of an element.

    4.146 GI: generic identifier.

So, GI <==> generic identifier <==> element type. Or am I missing something (not so) obvious here?

So, are boy and girl of the same element type? The definitions imply (I think) that an element type is identified by a unique GI, and vice versa, so it looks to me that there should be no distinction between the two. Thus, boy and girl are of different element types (and have different GIs). Please correct me if I misunderstand.

>See also the definition of a GI:

(See above)

Perhaps there was some previous distinction between the two that is now lost in time? Is this an example of legacy terminology?

>The idea seems to be that a generic identifier specification is used
>to give in an instance the type of an element, once the parser has
>determined that an element is beginning to happen.  The terminology
>seems so obfuscatory to me that I see no benefit to the distinction for
>SGML itself, let alone for XML, but maybe that is because I lack a legal
>background :-)

I (me and myself) do hereby instantiate my total concurrence with your most perspicacious and eloquent statement regarding obfuscation in SGML. (Agreed ;-)

<opinion value="0.02 $CA">

Since when do lawyers write programs? Never! ;-)

They have lackeys (us) to do that for them, and if the lackeys can't read the spec, what kind of spec is it? XML, from my perspective, is a minor revolt by the lackeys (and their good friends) to get the spec pared down to something "reasonable". I just hope that the discussions about what is "reasonable" don't lead XML into interminable wrangling. Tim Bray's earlier point about the importance of a (perhaps) imperfect, yet SOLID, specification is well taken.

</opinion>

   >[. . .Good point about SGML terminology deleted. . .]

 - Russ

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)