[
Lists Home |
Date Index |
Thread Index
]
Gavin Thomas Nicol wrote:
> On Thursday 31 January 2002 04:49 pm, Jonathan Borden wrote:
> > It is not a simple fact at least if we are still talking about XML.
> > XML 1.0 says that the _type_ of an element is its name or GI.
>
> 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? Because if we are using different definitions for terms, its
really hard to have a meaningful discussion. XML 1.0 does say this, and an
element's name _is_ different than other attributes of the element. Purely
from a definitional standpoint.
>
> The markup tree can be interpreted as one sees fit.... in other
> words, the markup tree is really not much more than an attributed
> tree/AST. You can interpret that tree as you like. In a statically
> typed/validated system, you would run through and say "this node has-a
> gi of 'foo', so therefore, I will say that it 'is-a' or 'is-of' the
> 'foo' type", and then validate that type association. This is roughly
> what happens inside a compiler... and is the reason why I was an early
> supporter of making validation orthoganal to parsing.... validation is
> projecting a type system over an untyped tree.
Right on all accounts ... and when we move beyond DTDs, schema validation
_is_ orthogonal to parsing.
>
> > In any case it is not typical to equate "isa" and "has-a"
> > links and I suspect that if you do so, you will lose processing
> > capabilities.
>
> My assertion is that there is no 'is-a' relationship in XML unless it
> has been projected over the instance by a processor... and that 'is-a'
> requires 'has-a' to operate. In other words, you lose no processing
> power whatever....
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.
I think what I am saying should be straighforward:
1) I find it useful from a processing POV, to consider what XML 1.0 calls a
type, what is traditionally called a type
2) It is traditional to distinguish "isa" from "has-a" links, and I find
this useful, from a processing POV, as well.
> My entire objection to namespaces is that they propogate the myth that
> 'is-a' relationships exist at all. The name of a thing and the thing
> are logically distinct entities, and names are open to interpretation.
> The *thing* though, exists.
What is the myth? "isa" links have been used forever. A "name" is a
character string, right, what is open to interpretation? But please tell me
about this "thing" that is different from its "name". I suspect that if you
can describe it with enough precision that the answer to these issues will
become apparent. For example do you wish to describe each and every element
that exists in the entire universe as a distinct "it" that "has-a" set of
properties. That would be tedious. Rather, you might want to make statements
like:
"it isa element" where "element" represents a class.
and then you will be able to describe the properties that an element "has".
It turns out, again speaking of ASTs, that this is _exactly_ how XML 1.0
itself is described: in EBNF.
(I've made the case before that the "property set" of XML is derived
precisely and trivially from its EBNF (e.g.
http://www.openhealth.org/XSet) )
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. So the reason that we reserve a special place for the "name" of
something, as opposed to any of the other "properties" it has, is simply
that it is useful, for example:
/foo/bar/baz[@bop='32']
it simply is compact and readable and hence useful to refer to an
element/node by its name, instead
/*[@xml:name='foo']/*[@xml:name='bar']/*[@xml:name='baz' and @bop='32']
nah!
Jonathan
|
