|
Norman, your words about Architectural Forms are insightful and
inarguable, and it's also pretty clear that you have been there and
done that. The argument about XSLT being just as good -- or a whole lot better -- for much the same purpose as AFs is not a new one. But nobody has (yet) demonstrated how such an approach can hit the mark that the design of AFs was aiming at, and that it did, in fact, hit. The mark I'm talking about requires a brief discussion. * Information often turns out to have purposes that were not anticipated when it was originally uttered. Indeed, the raison d'être of GML, and its descendants is that the breadth of data's re-usability is proportional to the generality of the applicability of its internal metadata. (In ?ML terms, its markup.) * Being able to automate the extraction of one document from another is a great thing. No doubt about that! But it should not be confused with the ability for the document itself to declare its own actual-and-testable breadth of applicability across some range of applications. In the latter case, it's not enough to know that, by applying some particular external transformation specification, <x> can be extracted as <y> or <z>. It is also necessary to know that <x>, just as it sits there, is in fact also both <y> and <z>, so, dear maintainers of these data: "BEWARE, lest you screw them up!" With AFs, a maintainer can always test whether those who need <z> have been inadvertently disenfranchised , even if the maintainer doesn't have a clue what <z> is all about, really, as long as the constraints imposed by the <z> interpretation are specified adequately. I have a dark suspicion that the real ugliness of AFs is that they so readily and easily point the finger of blame at those who can't be bothered with <z>'s needs, but who nevertheless want to appear as though they really do care a whole lot. Then, when problems crop up, who's fault is it? Not theirs. It's in the fact that the people of the world just haven't figured out how to work together yet. "Maybe what we need is [insert sexy-sounding web-based idea] to support more effective collaborative work!" So the XSLT-vs.-AFs argument really isn't about whether XSLT is just as good at extracting one document from another (which it certainly is, and much more besides). For me, the argument is really about the distinction between source and rendition, and whether the fact that de-facto-collaboratively maintaining the full breadth-of-applicability of a given source is worth acknowledging and supporting. Everything in my own experience says that it is. (Of course, everything in my own experience also tells me that everybody must take responsibility for the security of their own data. Now there's an idea that really has no commercial value!) On 04/29/2016 12:28 PM, Norman Gray
wrote:
|