[
Lists Home |
Date Index |
Thread Index
]
Lack of clarity benefits no one. Lack of precision
hurts everyone. No arguments from me on these, but
we have to recognize the work that goes into reconciling
these viewpoints and help out when we can if we have a
stake in it. That's all I'm saying.
ISO doesn't have mystical powers. They have different
customers with different policies. What we get by
working with ISO is a slower outer loop and fast
inner one. This benefits those who need predictable
specifications and standards. When we can get the
examples you cite in front of the ISO editors,
we can get a better result. It has worked for
the VRML X3D groups and there is no reason save
resistance based on mystical assumptions about
other groups, it shouldn't work here. I think
it is working.
But all this thread is about is figuring out if
the baby in the bathwater of AFs can be raised
by the markup community, a community that spans
all of the groups we mentioned here, to be a
productive grown-up. That seems like a reasonable
and useful goal.
len
-----Original Message-----
From: Frank Richards [mailto:frichards@softquad.com]
Sent: Friday, February 01, 2002 11:01 AM
To: Bullard, Claude L (Len)
Cc: xml-dev
Subject: RE: [xml-dev] 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@ingr.com]
Sent: Friday, February 01, 2002 11:06 AM
To: 'Frank Richards'
Cc: xml-dev
Subject: RE: [xml-dev] 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@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.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
