[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Co-operating with Architectural Forms
Len, First, clarity vs. specificity is the excuse for the difference between RS-232 and Mil 188-C. It doesn't excuse having to buy the SGML Handbook. Second, you continously ascribe some mystical extra goodness to the ISO family of specs vs those from the W3C. This on top of any technical merits of AF. I actually admit some benefit there. But as a long time user of specs by the equally nongovernmental SAE and IEEE, if find it far more limited than you seem to. And I find the undeniable lack of clarity in those ISO specs to be a more major drawback than you seem to. Frank -----Original Message----- From: Bullard, Claude L (Len) [mailto:clbullar@i...] Sent: Friday, February 01, 2002 11:06 AM To: 'Frank Richards' Cc: xml-dev Subject: RE: Co-operating with Architectural Forms Clarity is always valued and you aren't the first person to note that those specs are a tough read. On the other hand, see Eliot's defense about internal consistency over readability. One can make a case for either depending on how one views the relationship of marketing to a naive audience over making the spec tight. I know the authors of those specs, and yes, they tend to favor tight over sellable. I had to learn the stuff from deRosier and Durand's book and Eliot's Practical Hytime manuscript. Otherwise, 99% of the authors on this list for XML and XSLT books would be out of work. The general idea of XML-Dev is to nail down such things and help to clean them up precisely by giving such feedback. We can argue endlessly about what is ugly or what is precise, but we are better served as this thread is quickly proving, to engage each other and get the common understanding that both helps to clarify the spec and to improve it. We have the right people here to do that, and they have a good time doing it, so what the heck.... The goal was to ascertain by discussion if there is a unique utility to AFs that implementaion could bring to our world of parts and assemblies. As Gavin points out, The Web is yet another application on the Internet. That is the case, and we can do better if we have better tools. len -----Original Message----- From: Frank Richards [mailto:frichards@s...] >> We gotta get past this "ugly" thing. The authors of these texts are here with us and can help sort the English. The editor of ISO 8879 is an approachable guy. We really can approach these tasks as a global markup system task and keep all of the useful options alive. But if this starts out as a catfight over who can write the simplest sentence, we are all losers. << Uh, wrong. This is not in general government contracting. If the people who have to implement specs can't understand them, the specs won't be implemented. And having to get help from the specifiers here on xml-dev goes against the whole idea of using an ISO spec in the first place: I and any other geek in the world should be able to figure out how to meet a spec, and whether an implementation meets that spec, without needing personal guidance from the author or a separate (and specific) book from Oxford University Press. In my previous life as an electrical engineer I had occasion to read many specs from CCITT, EIA and the IEEE. (Admittedly none from ISO) Until the 8879 set of specs rises to the standard of comprehensibility set by these organizations, rather than falling to the standard set by the USDOD (actually below it -- you can parse a mil spec if you try hard enough. 8879 cannot be done without a gloss) those specs will, if not fail, at least be severely handicapped in the marketplace of ideas.
|
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
|