Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Markup perspective not code (wasRE: Re: URIs, co
 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
