[
Lists Home |
Date Index |
Thread Index
]
each standard listed seems to have a different history and purpose. in
the case of ANSI C it was to put a lid on something that lesser mortals
couldn't deal with. lack of variable typing in C. there was a few minor
additions to the original - such as const, a couple of extra #'s such as
#pragma, standardised library - <displeasure> gnu keeps changing
</displeasure> but mostly it was the prototype function definitions and
the typing of arguments. i dutifully converted most of a hundred
thousand lines or so of code for no substantial benefit (actually i
never really converted all of it, just most as i modified it) and to
this day wonder why all the fuss. and the back door was left open to say
that any comforming compiler must also accept "classic" or "k&r" c. it's
not really a standard, just the settlement of an argument. c++ is pretty
much the same. wrappers around functions and variables - in fact the
first c++ "compilers" weren't really - they just converted c++ to c.
posix was another way to settle an argument that everyone including gnu
uses more as an idea of what might have been rather than a standard to
comply with. and worse it hasn't been revised to take into account the
needs of current operating systems.
that's one view. there's a separate problem, i believe, for it in
general and particularly at higher levels such as xml. we really are
playing with massively complex systems by any definition. and to make
these things work we often have to reach agreement with each other on
how to interoperate - from cpu to peripherals to data stores to networks
to other corporations etc.
i see most of the "standards" work out there at the moment as more like
the rfc process - we agree on how to talk to each other. call it what
you like, but basically we agree that if i'm going to send you a message
here's how it will look..... we've been doing it for years with things
like edi, but now we are trying in a broader sense.
i'm not much interested in what we call it, or how we get there, so long
as we get some agreement. after all it really only affects us in the
industry and how we achieve goals.
what i do object to is reaching agreement and then some company telling
me that - "oh, i forgot to mention that every time we use this agreed
format you'll have to pay me" - it's like a gun at the head and should
be stopped, but the process and what we call it can be anything - so
long as we can all work with it.
rick
On Fri, 2004-04-30 at 23:39, David Megginson wrote:
> Ken North wrote:
>
> > Although I'm not Len, here are some ISO standards that people in computing
> > have encountered over the years:
> >
> > Characters sets and coding (ASCII, OCR-A, OCR-B, MICR, bar codes)
> > Audio and video compression (MPEG 1, 2, 4)
> > Graphics: GKS, PHIGS, CGM, JBIG
> > Messaging/mail: X.400
> > Languages: C, C++, Ada, SQL, FORTRAN, COBOL, Pascal, Modula-2, POSIX, CLI
> > Storage, networking, bus interfaces: SCSI, SCSI-2, FDDI, CSMA/CD, VMEbus,
> > Multibus, HIPPI, RS-232/V.24 electrical
> > Markup: SGML, RELAX NG, VRML
> > Geocoding: ISO 19100 (19107, 19108, 19123, 19127)
> >
> > In general, ISO, IEC and ITU (formerly CCITT) collaborate on a variety of
> > standards -- (e.g., ISO/IEC 7498 Open Systems Interconnect). There are also
> > standards for things such as how many dead pixels are acceptable in LCDs.
>
> Thanks for the list, Ken -- it should provide a reasonable basis for
> comparision with computer tech specs that have come out of processes other
> than ISO's and ANSI's. Some of these I would disregard, either because they
> have not caught on (i.e. the graphics formats), or because they are
> primarily rubber-stamps on existing, outside work (such as RelaxNG or VRML);
> however, some represent real, from scratch work (such as SGML) or
> substantive, widely-accepted modifications to existing specs (such as SQL92
> or ANSI C and C++).
>
> Now, any discussion comparing various standards and specification bodies
> needs to show how, for example, the ISO process has caused, say, ANSI C++ to
> be a fairer, cleaner, more widely-implemented, less vendor-bound, freer,
> and/or less bug-ridden spec than non-ISO specs like XML or HTTP.
>
>
> All the best,
>
>
> David
>
> -----------------------------------------------------------------
> 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://www.oasis-open.org/mlmanage/index.php>
>
|
