-----Original Message-----
From: David Hunter [mailto:david.hunter@mobileq.com]
Sent: Tuesday, August 28, 2001 1:56 PM
To: xml-dev@lists.xml.org
Subject: RE: Enlightenment via avoiding the T-wordWow. 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@allette.com.au]
Sent: Monday, August 27, 2001 10:57 PM
To: xml-dev@lists.xml.org
Subject: Re: Enlightenment via avoiding the T-word
From: "Fuchs, Matthew" matthew.fuchs@commerceone.com
> 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