Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
