[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote
>why would you say vocabularies are defined by programmers? No doubt
some
>are, and it shows:-) but often (and ideally) the markup language is
>explictly designed _without_ a programming basis.
Agreed that markup designed by programmers is often horrendous, the most
common failings seem to me to be:
1. Translating some API directly to an xml structure in the
easiest(by easiest meaning least thought given) manner. This leads to
bloated specifications.
2. Following some processing model that they prefer which makes
the structure hard for others to work with.
3. Just making a straight flat file(this is really an incident
of number 2 I think and in some cases of number 1)
>Different programs presumably then operate on that markup in different
>ways, but that shouldn't necessarily be a design criterion of the
>language. docbook is docbook whether it's implemented in dsssl or xslt
>or built in to a proprietary editor.
I think it sort of should be a design criteria of the language, a
tertiary criteria but a criteria nonetheless. Why? Mainly because I
think if you specify xml formats that are harder to work with through
some ways then you damage interop.
All of which makes me think of Sean Gallagher's article on the hidden
cost of xml tags; I tried googling for the article but couldn't find
it(semantic web my endtag!) so I haven't included a link, no doubt you
are familiar with it anyway. In this article he concludes maybe the
people who design these specifications are the people who have to
implement them, with some swipes at acamedicians if I remember rightly.
This leads me to what Simon St. Laurent wrote:
> Once programmers started _adding_ to markup practice rather than
reducing
>markup practice, we wound up with huge mashes of nastiness that take
>eternity to sort out. Case studies: namespaces, W3C XML Schema, W3C
XML
>Query....
I don't know about that, namespaces don't seem to me to be a huge mash
of nastiness because of addition to practice but mainly because of some
few poorly thought out consequences, of course it is easy for me or
anyone to define something thought out without the benefit of hindsight
as being poorly thought out. I'll have to agree with the W3C XML Schema
and W3C XML
Query observation, but I know many others don't agree.
Anyway I have seen specifications authored by non-programming domain
experts(or at least I assume they have been so authored, no doubt they
had some technical help but let me not undo my argument by splitting it
too fine); these are often no better, again contravening Mr. Gallagher's
wise precepts about hidden costs and suchlike by verbosity and often
doubling markup structures in order to delineate some very slight change
in logic.
Just as often these specifications attempt to match the structures that
the domain experts were used to working with before, as a general rule
non-hierarchical structures, thus replicating many errors of "xml
dialect design by Programmer".
It seems to me that probably what one needs is for specifications to be
authored by someone who can stand in between the worlds of the
programmer and the domain expert, mindful of what the programmer will
have to do to work with the new format, and capable of analyzing the
structure of individual domains, to render them to their essence in xml.
This class of worker would also be able to analyze other specifications
dispassionately and tell the programmer, this spec is good, this is crap
and will be important for a year before sinking under its own impossible
implementation requirements, and so forth. It seems to me that this is
something the community lacks and thus the task goes instead to
Programmers, and I think this was sort of what James Fuller was thinking
of earlier in this thread when he wrote:
> it seems to me that xml-dev is, and should be, finally about the
> development of skilled XML--that is, markup--and much less about the
> ancillary business of implementing appropriate algorithms for
> processing the wonderful subtleties which the markup grows to
> describe.
|
