[
Lists Home |
Date Index |
Thread Index
]
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@softquad.com]
>>
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.
|
