[
Lists Home |
Date Index |
Thread Index
]
On Thursday 31 January 2002 06:50 pm, Jonathan Borden wrote:
> > I think this is a misnomer carried over from the ancient days of
> > SGML.
>
> When you say "misnomer" do you mean that XML 1.0's usage of the term
> "type" as in:
>
> "The Name in the start- and end-tags gives the element's type..."
> http://www.w3.org/TR/REC-xml.html#dt-stag
>
> is wrong?
Yes.... or at least ambiguous.
I think the term "type" here is often interpreted to mean "type" in
the sense of "int", "float" etc. as found in strongly typed computer
programming languages. Perhaps for SGML, which required DTD's , and so
to a degree was statically typed (hah!) it was similar, but I think
for XML, the notion of "type" is really much looser.... very much
closer to the Common Lisp way, where type is by projection, as Joe
pointed out. In practise, this was usually true of SGML too...
> XML 1.0 does say this, and an element's name _is_ different than
> other attributes of the element. Purely from a definitional
> standpoint.
Yes, because it is required. Whether this is largely a feature of
syntax could be a point of discussion, though not overly interesting.
Just to clarify terminology, I am using attribute in a slightly wider
sense than XML... more like the notion of "field" or "named data
member".
> I am not sure what you mean. I am saying that I find it useful from
> a processing POV, to consider an element's name, just as what XML
> 1.0 says, its "type" and moreover that this defines the "isa" link.
Sure. I think many people find this useful. My point is that the
'is-a" is not intrinsic... though the XML specification's use of the
word 'type' might lead you to believe so. The application decides how
'is-a' relationships are decided.
> What is the myth? "isa" links have been used forever. A "name" is a
> character string, right, what is open to interpretation?
I should have been more precise, sorry. When I say "isa is a myth", I
meant "isa links are intrinsic is a myth". Again, my assertion is
that 'is-a' only exists in the context of a given interpreter.
> At the end of the day, we do all this because it is useful, and the
> utility of thinking about namespaces in one way or another is purely
> the usefulness of doing so.
Sure, in the context of a given application, one style is preferrable
to another mostly because of it's utility.
|
