|
Just as code is data and data is code, meta-data is another form of data. Erik' quotes are all taken from https://groups.google.com/d/msg/comp.lang.lisp/8eUxiibm_zA/C...: > [...] is INTENDED to be a MODIFIER for FOO and NOT part of the CONTENT that FOO is marking up "The intended use has less to do with it than the notion that you can
define what is meta-information and what is information at the time you
want to decide whether something goes in an attribute or a sub-element.
My argument is that this is impossible. Whether it is meta-information
or information is a reflection of the actual use, not the intended use. However, given that the mechanism was created, and I will argue that it
was not so much created as it was never thought possible to be any other
way, it was used to define several language properties. "Now that we
have this, would it not also be nice to have that." This means that
several of the attribute types grew very far apart from the contents of
sub-elements and you sort of "had" to use them as attributes, but only
sort of, because the application can and does define the semantics of
everything, and if you want ID and IDREF, you can make the same choice as
you would in Common Lisp to use symbols or a hash tables of strings." > Actually, let me try to be excruciatingly precise: my claim is that it is not self-evident that a syntactic distinction between data and metadata is useless. Hence a rendering of XML into sexprs that preserves this distinction is defensible, and dismissing it in the pejorative terms that Erik uses is not justified. "No, there is nothing that requires there to be element attributes as a
distinct concept from element contents. There are, however, a number of
practical things that follow from making that arbitrar distinction which
can look like rationales, but if you ask yourself "why can it not be a
subelement", there are no real answers, only appeals to the idea that
there somehow __have to be a distinction. It took me years to figure out
that the whole attribute idea is completely vacuous, and I worked with
the creator of SGML himself for several years on several SGML-related
standards and projects. I started writing "A conceptual introduction to
SGML" back in 1994, but as I had pained my way through five chapters, I
had to realize that it was all wrong. There was a basic design mistake
in the whole language framework. That mistake is that simply put: "what
is good enough for the users of the language is not good enough for its
creators". Each and every level of "containership" in SGML has its own
syntax, optimized for the task. Each and every level has a different
syntax for "the writing on the box" as opposed to "the contents of the
box". This follows from a very simple, yet amazingly elusive principle
in its design: Meta-data is conceptually incompatible with data. This is
in fact wrong. Meta-data is only data viewed from a different angle, and
vice versa. SGML forces you to remain loyal to your chosen angle of view." So, the opinion seems to be that the arbitrary structure you put between meta-data and data at the moment you create data is not necessarly well-suited for people using your data: then, despite being useful, the syntactic distinction becomes an annoyance. By the way, Erik's dissmissal is (1) the result of years of experience working on SGML, and (2) not pejorative, but argumented. He is the one arguing against the "self-evidence" of attributes. |
Sorry, the phrase "incredibly stupid" is pejorative.
And I don't really care if his position is the result of years of experience. It's wrong nonetheless. There are certainly stupid things in SGML, but the attribute/element distinction is not one of them. (Or at least, it's not a no-brainer that this is one of the stupid things in SGML, so if you're going to claim that the attribute/element distinction is stupid you need to provide a cogent argument to support your position and not just proclaim it as self-evidently true.)