> lee@sq.com wrote:
>> > Peter Murray-Rust wrote:
>> I still don't know if there is a difference between 'GI' and=20
>> '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 <=3D=3D> generic identifier <=3D=3D> 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=3D"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@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)