[
Lists Home |
Date Index |
Thread Index
]
And the lack of precision from other specs
has made creating interoperable applications
just as difficult plus stretched out the
time to get that done to years over months, quite
the opposite result promised.
This is a useless exhaustive thread. The concepts
are the prize, and any process we use to get
these out front in terms we all can agree to
that works works for everyone. The ISO vs W3C
spec clarity thing is just a hobgoblin. Of course
we want clarity AND precision. Heck, who wouldn't.
len
-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org]
Sent: Friday, February 01, 2002 11:05 AM
To: Frank Richards; Bullard, Claude L (Len)
Cc: xml-dev
Subject: Re: RE: [xml-dev] Co-operating with Architectural Forms
2/1/2002 11:05:50 AM, "Bullard, Claude L (Len)" <clbullar@ingr.com>
wrote:
>
>Otherwise, 99% of the authors on this list
>for XML and XSLT books would be out of work.
Uhh, if the specs were simple and readable we would simply have to
make an honest living :~) I vaguely remember doing that, back in
the days before XML was the Next Big Thing. It wasn't so bad ... I'd
happily go back to a life of honest toil in the vineyards of software
if clear, simple specs were part of the bargain! <grin>
I completely agree with Frank Richards:
> 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.
Or maybe, "the specs won't be implemented in an interoperable
manner." *IF* some of these "tight" ISO specs have powerful ideas in
there somewhere and the world is the poorer because they haven't been
implemented, recasting them in a form that is readable outside the
community that devoped them and defining a less "ugly" syntax should
be a high priority for their advocates.
|
