Wow. This seems to me like a pretty hard-line
stance. Is it shared by many? i.e., that <name> [in a
particular namespace] means one thing and one thing only, and that if you want
a "name" for something else, then you'd better find another label for the
element that contains it? So, instead of
<stuff>
<person>
<name>John</name>
</person>
<company>
<name>The
Company</name>
</company>
</stuff>
you should always have
<stuff>
<person>
<person-name>John</person-name>
</person>
<company>
<company-name>The
Company</company-name>
</company>
</stuff>
or some such? I myself, and probably others on the list,
would have said the opposite is good practice - don't include the name of the
parent element in the name of the child element. (I do the same when
designing databases, not that I do that too often. I never include the
table name in a column name.)
So I guess I am most uncomfortable with the term "best
practice" - I don't think that there is a whole lot of agreement on this
issue, to put it mildly.
-----Original Message-----
From: Rick
Jelliffe [mailto:ricko@a...]
Sent: Monday, August 27, 2001 10:57 PM
To: xml-dev@l...
Subject: Re:
Enlightenment via avoiding the T-word
From: "Fuchs, Matthew"
matthew.fuchs@c...
> To start, people might actually try working with
XSDL local types before
> voting. I realize
that's not necessarily the American Way, but it might
> help.
I would recommend the opposite: that people avoid local names
like the plague
for any public or non-experimental
schemas.
Don't give different things the same name. If you have two
people who
want to use the same name, get them to duke
it out or allocate different
namespaces. The
idea that it is more readable to have equivocal names
is bogus.
The least good reason for an XML schema language to support
something
is that it makes large queries easy, or that
it fits in with one particular
programming language.
Carts before horses: an XML Schema language
should
support and encourage good XML documents and good markup
practise.
How
should it be? Here's how I see it:
1) The basic semantics of an element or attribute should be
given by its name;
for any namespace the general
semantics of a name should not change.
So a
<line> should always be a drawn thing; or always a text line; or
always
a joke, but never one thing in one context and
another thing in another context
within the same
namespace or locally.
1a) Attributes are local names, but their semantics
should not be local to the
element, but global
to the namespace of the elements to which they adhere:
an *:*/@dog should have the same basic semantics.
1b) An element with a
local names with different basic semantics is an innovation
of practise which is bloating incrementalism to support, and we
would be
better to be rid of it.
2) The specific content model and allowed attributes of an
element
may change utterly according to other markup.
2a) However, parent context is not enough to model well
the kinds
of constraints found in real
situation.
2b) There is a feeling from some that the separation of
static schemas
(for storage) and dynamic
schemas (e.g. Schematron and co-occurrence
constraint schemas or business rules schemas) is useful.
There should be no requirement to support bad markup. Elements
with
different basic semantics but the same name is
bad markup. There should
be no requirement to
support solutions that don't make anywhere near
60/40,
let alone 80/20. IMHO the limited context provided by XML Schemas
do not meet the minimum mark. Furthermore, since they
encourage the
use of elements where attributes would
be more appropriate, it can
positively discourage good
markup.
Cheers
Rick Jelliffe