[
Lists Home |
Date Index |
Thread Index
]
David Megginson <david@megginson.com> wrote:
| Tim Bray writes:
[on jargon as a barrier to comprehension of AFs]
|> I disagree. While I still dislike the AF attribute remapping syntax,
|> I think there was a whole complex of great ideas lurking in there that
|> failed to succeed because the language used to describe them was more
|> or less completely impenetrable.
| I did my best to promote AF's right around the time XML 1.0 came out,
| but I agree with Tim that language was the biggest barrier to adoption.
Would more folksy terms (with perhaps a note in parenthesis to the correct
jargon) have made things more palatable? I really don't know, because
beyond user-friendly terminology there has to be reasonably clear examples
of the subject matter.
In my own case, it was a matter of acquiring the jargon - and with that,
the "why"s - after I had already had a taste of AFs - the "hows" - while
playing around with SP 1.1 upon reading this:
http://groups.google.com/groups?selm=9606101513.AA03030@jclark.com
At some point, it clicked that a) the element type name is actually just
the value of another attribute ("generic identifier"), and b) this is not
the only attribute by the name of which processing is, or even should be,
triggered (that is, look for *some* attribute by name, and then examine
its value to dispatch): GI-based processing is only a typical but still
special case. Note, for example, the special status of HTML's CLASS
attribute in CSS: that's a classic application of bargain-basement AFs.
Attribute based processing is where it's at. Once that's taken on board
it isn't a long step to thinking in terms of the values not being single
names but association lists of names...
And everything else is an application. Just as AFs are an application of
the rubric (and for that matter, could do with a rethink+rewrite).
|
