[
Lists Home |
Date Index |
Thread Index
]
On Monday, Nov 3, 2003, at 14:43 America/Detroit, Dare Obasanjo wrote:
>
> [Dare Obasanjo] I haven't reviewed the minutes yet but it seems
> contradctory to state that more research is needed before
> specifications
> can be created then go ahead and recommend a working group. Unless I'm
> mistaken there currently isn't a research-focused W3C working group nor
> is there a W3C working group that doesn't produce specifications.
>
I just want to emphasize that Liam said -- the workshop raised lots of
questions that need to be answered, but there needs to be some
organized and collaborative way to answer them. A lot of discussions
were concerned with trying to figure out whether apples were being
compared with oranges or not. It will take a fair amount of work --
worthy of a WG, not just a mailing list -- to determine whether the
speed advantages that some reported are from improved infoset
serialization, or from something else. Conversely, how much scope for
improving XML 1.0 parsing is there without mucking with the syntax?
Having a common testbed and data sources so that controlled experiments
-- changing one variable at a time can be conducted and the results
benchmarked-- is needed to answer such questions reliably.
Sure, this conception of a working group is something a bit new for the
W3C. I'd argue, however, that the XML world would be a better place
if the W3C had spent more time up front investigating what the problem
is, instead of inventing solutions and assuming that they solve
somebody's problem. In a world where the leading vendors seem less and
less interested in developing common, IP-unencumbered solutions at W3C,
preferring to go it alone [e.g. the Longhorn stuff] or create ad-hoc
coalitions [e.g. the various MS-IBM-BEA collaborations in the Web
services arena], this seems like a quite sensible use of the W3C's
resources. As Liam noted, the conclusion might be that there's no
problem that better code can't solve, or that some existing solution
such a ASN.1 or gzip or whatever solves it just fine for the majority
of use cases.
|
