On Fri, Oct 12, 2007 at 03:56:19PM -0400, Costello, Roger L. wrote:
> I am putting together a list of approaches that people use to create
> tag names and attribute names. I am interested in your input.
> Are there other approaches that people use to create tag names and
> attribute names?
I am fond of:
http://www.valinor.sorcery.net/names/names.cgi?which=default
> 4. There exists a data requirements document; tag and attribute names
> are distilled from the requirements document. (I am not clear on how
> tag and attribute names can be systematically distilled from a
> requirements document; do you have insights on how to do this?)
This probaby only works if you write a requirements document that
contains element and attribute names... which would be a little
unusual, I think.
The most important things about element names are
* don't in general rely on them being displayed to a user.
They may need to be localised, and the localisation might itself
need markup (e.g. ruby).
* they should convey a sense of what is represented, just like
variable names in a program. BookTitle is better than Field810
in most cases, MARC notwithstanding :-) because it can be usefully
interpreted by some of the people who work with it rather than
none of them, even though it is not language-neutral.
* it can help to have a convention for element names that represent
properties, e.g. using
socks.colour
and another convention for multi-word names, e.g.
lesser-demon-of-hell
angel-of-destruction
You can then migrate systematically between elements and structures,
e.g. from socks.colour to socks/colour.
* human-readable content belongs in element content, not in attribute
values. HTML (as augmented by Marc Andreeson et al.) got this wrong
with the alt attribute, which should have been a child element of img.
<Indoth pasmel="cracleneayne">Liam</Indoth>
--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/
