[
Lists Home |
Date Index |
Thread Index
]
Well David, you don't spend much time working
contracts and proposals, I guess. Policy makes
a big difference there. They call it process; you
call it poison, but effectively, without it, there
is no accountability or traceability, and in the
big game, without these, watch your tax shekels
go down rat holes (why states have competitive
bid laws, sunshine laws, and so on).
So sure, it is what people do that matters, and
given a lack of understanding, they follow policy.
In the case of SAX, it mattered a lot that the technology
be there for certain problems. Now MS has a different
event-based parser that isn't SAX. In this case, since
SAX isn't a standard under any of the cited organizations,
I guess it makes no difference, but were it, some procurements
would be forced out of using what would be called
proprietary alternatives irrespective of applicability
or costs. These aren't black or white engineering
decisions. That would be nice but naive.
len
From: David Megginson [mailto:david@megginson.com]
Bullard, Claude L (Len) writes:
> I interpret it to favor the W3C specifications even if they are
> works in progress over other standards organization works even if
> these are complete. That eliminates competitors if there is a W3C
> candidate.
> So we aren't to compare the relative merits of each but take the
> W3C uber alles. That's bad policy.
[snip]
Now, now, Len -- I'm not sure it's that bad. As you have pointed out
many times, what matters is what people actually do, not what spec
writers invent or marketing departments announce support for.
Initially no one made a big deal of announcing their support for SAX
or RSS -- they just quietly used them. It was a decision made on the
engineering level rather than the management level, so it actually
mattered (and tended to solve real problems rather than hypothetical
ones). Ditto for HTML in the early (pre-1994) days and TCP/IP even
earlier.
> They do need to clarify and they do need to understand that some
> technologies will have better alternatives for some cases. RELAXNG
> is probably the star case for that.
If there is a real and pressing engineering problem that schemas
solve, then the winner will be a spec that solves the problem (not
necessarily the best one, but still one that works); if there's not a
real and pressing engineering problem, then the spec with the best
marketing will win automatically, but in that case, who cares?
|