The IETF slides are interesting. This approach feels more &quot;agile&quot; than ANSI, but Paolo&#39;s point about re-writing the entire spec if we were to move away from ANSI needs to be addressed.<br><br>Having two standards is a bit like having two watches...
<br><br>Steve<br><br><div class="gmail_quote">On Nov 14, 2007 8:08 PM, John Dougan &lt;<a href="mailto:jdougan@acm.org">jdougan@acm.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;ve found that the history of ANSI standard language efforts is a<br>checkered one. &nbsp; Myself, I&#39;d rather be using something like the IETF<br>process:<br><br><a href="http://edward.oconnor.cx/2006/11/DIY-standards-body" target="_blank">
http://edward.oconnor.cx/2006/11/DIY-standards-body</a><br><a href="http://www.ietf.org/rfc/rfc2026.txt" target="_blank">http://www.ietf.org/rfc/rfc2026.txt</a><br><br>The IETF process appears to be more inclusive and much more resistant to
<br>vendor lock. &nbsp;I don&#39;t think a $1200 fee is much of a guarantee of<br>seriousness....it hasn&#39;t worked before and is enough to eliminate much<br>of the open source community.<br><br>Cheers,<br><br>&nbsp;-- John Dougan
<br><div class="Ih2E3d"><br>Janko Mivšek wrote:<br>&gt; Bruce Badger wrote:<br>&gt;&gt; On 14/11/2007, Janko Mivšek &lt;<a href="mailto:janko.mivsek@eranova.si">janko.mivsek@eranova.si</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt;&gt; I think Peter&#39;s question was targeted more to the accessibility of
<br>&gt;&gt;&gt; final<br>&gt;&gt;&gt; standard. And here another question opens: why won&#39;t we choose some<br>&gt;&gt;&gt; other standards body, which has more open politics to final documents?<br>&gt;&gt;&gt; OMG is coming to my head ...
<br>&gt;&gt;<br>&gt;&gt; We have the ANSI process rolling now, Janko. &nbsp;If you are seriously<br>&gt;&gt; suggesting that we change horses then I think you would need to put up<br>&gt;&gt; a more detailed proposal so we can compare the alternatives.
<br>&gt;&gt;<br>&gt;&gt; In the meantime I suggest that we keep working on the bird we have in<br>&gt;&gt; our hand, viz ANSI.<br>&gt;<br>&gt; Well, we are rolling first and foremost a Smalltalk standardization<br>&gt; process and &nbsp;ANSI as a standardization body was IMHO chosen more by
<br>&gt; inertia, because existing standard is ANSI. So, the race started for<br>&gt; Smalltalk standard and yes, you started ANSI path, but that doesn&#39;t<br>&gt; mean we need to continue that path, we are not too deep yet anyway.
<br>&gt;<br>&gt; If there is some better standardization body, we should at least<br>&gt; consider it. Better for me is more open on final documents, not<br>&gt; necessary less costly. That yearly fee is kind of a guaranty for
<br>&gt; seriousness.<br>&gt;<br>&gt; What others think about that?<br>&gt;<br>&gt; JAnko<br>&gt;<br><br>--<br></div><font color="#888888">John Dougan<br><a href="mailto:jdougan@acm.org">jdougan@acm.org</a><br></font><div>
<div></div><div class="Wj3C7c"><br><br>_______________________________________________<br>ANSI-Smalltalk mailing list<br><a href="mailto:ANSI-Smalltalk@lists.openskills.org">ANSI-Smalltalk@lists.openskills.org</a><br><a href="http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk" target="_blank">
http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk</a><br></div></div></blockquote></div><br>