OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] SGML default attributes.

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:


On 29 Apr 2016, at 16:30, Dave Pawson wrote:

Thanks Chris. Food for thought.
"XSLT becomes the agent of architectural mapping,"

And it does step away from DTD's

Yes.† For those on-list who aren't tripping along their personal AF memory lanes at this point (mine has orchids with thorns, strewn all along the path), this might be the occasion to remark that a zeroth-order description of Architectural Forms is that they were a transformation of a document, specified within one or other DTD rather than in a separate transformation language.

This did not make for luminous syntax.† No.† But it was I think the conceptually Right Place for this transformation, it meant that that transformation could be implemented efficiently within the parser, and it meant that it was natural to conceive of the transformation as 'pulling' the AF instance document out of the DTD instance document, which is a Really Useful Idea.

I'm pretty sure that you could reimplement much of the AF plumbing with XSLT if you wanted to.† I speculate that you could get the same conceptual advantages by developing a syntax for describing the AF, with the same semantics as the HyTime standard described for DTDs, from which you then generated an XSLT stylesheet which extracted that AF instance from a suitable range of input documents.

Best wishes,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS