> Consequently, it seems to me that we can get too much wrapped up in
> whether this or that format is the "best" when it is better to see any
> of these formats as being simply intermediate stages, application
> specific languages that are better than proprietary ones because they
> can be pipelined, but not necessarily the best vehicle for storing
> domain specific knowledge.
Simple practical matter: pipeline processing technologies such as XSLT
are far better aligned for extracting element type info from GIs and
attribute info from attributes, rather than trying to hack at GIs
tunnelled through attributes (I know: I've suffered enough trying to
process such nasty XML). That's one of the arguments for using XML
formats with good semantic fidelity to the problem domain.
Granted, though I suspect this is ultimately the XML community's version of the multiple inheritance headache. A GI is not really generic. It has its own implied semantic; tunnelled attribute types in essence are an attempt to associate with such an element an alternative schematic interpretation, or, to put it into my terms, a metaphorical binding on top of the initial element. The problem, of course, is that creating that association is remarkably difficult within the confines of XML, especially since such bindings can potentially be multidimensional in nature.
Perhaps the solution here is to make it easier (its certainly possible with most schema languages) to define linguistic extensions that perform the associated mappings up front:
<myProp> ~ <h:dir class="myProp">
I know, this smacks a little too close to macros for my own comfort, and realistically such a change is of course just a transform away, but there are times that I think that this model actually makes more sense than working with complex GIs.
-- Kurt
