[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) wrote:
> Thanks to Priscilla, Henry, Bob and Jeff.
> That makes perfect sense. I'll forward this
> back to the X3D group. We are in the process
> of cleaning up the schema and DTD. I think I
> shall continue to use XSV, though, if for no
> other reason than to give feedback on what it
> detects in case that outs any bugs.
>
> If it isn't the gold standard, it ought to be.
Certainly there ought to be one. Like you, I'd hoped XSV would be that
one, in large part because there is no hope of writing a correct
processor unless you understand the specification, and Henry Thompson
certainly does.
But I also understand how such a project can't claim top priority on the
time of the few people, like Henry and Priscilla, who really understand
WXS in every detail. It is a darned shame that W3C doesn't own up to its
responsibility to _really_ assure its specifications are implementable
by putting its pool of volunteer labor to work _really_ implementing
them, and proving the implementation by offering it as the platinum rod
to be measured by.
The current process, where vendor interest in implementing a spec
suffices to prove implementability and marketplace competition is
expected to favor more correct implementations over time, need never
converge in even one correct implementation. This is clearly shown by
the fate of other standards, from SQL to CSS2. Correctness is not the
first goal of commercial implementations and never will be. Other
considerations, like performance, time to market, memory footprint,
internationalization, are significantly more important to vendors than
finishing off the last details of a spec, or changing an incorrect
behavior that has acquired a large customer following. This inertia
extends even to open source implementations, which compete in the same
marketplace as commercial offerings and, price aside, on the same
measures. Social factors interfere, as well; for example, it isn't
uncommon that committers in open source projects will resist fixing
corner cases if the fixes require rewriting significant amounts of code,
a situation where over-the-transom contributions are less likely, as well.
What is needed is an open source implementation of all significant
recommendations (the ones willing to stand up and admit they are
insignificant can be exempted) devoted solely to the goal of
correctness, developed in tandem with an open source test infrastructure
by which the implementation is proven. Such an implementation would be
highly unlikely to be commercially attractive in it own right, but would
provide a significant lever that customers could use to apply pressure
to vendors. The test suite, in turn, would give other implementors a
powerful tool, perhaps the most powerful tool possible, for producing
conformant products. Ideally, the reference implementation's initial
development would be done in tandem with the development of the
recommendation, but it is never too late to start.
Bob Foster
> Understand the problems of other consortia building
> on W3C specifications to create ISO standards, and
> you quickly see the problem of authoritative reference.
> Given multiple testers with different parsers, it
> is important to know which tool is the one to trust
> even if it has known bugs. Better the known than
> the unknown. While the situation may be getting
> better, schedules for other works are complicated
> by tool diversity.
>
> Systems like X3D that sit atop different consortia
> specifications, the OpenGL and Direct3D 3D languages,
> and then the multitude of device drivers underneath
> are in a boiling soup of bug sources. That should
> make the rich client application developers who must also use
> those subsystems more than a little nervous. So
> we may be forced toward reference implementations
> to get stability even if only in the legal sense.
>
> Betty is right. This is eerily reminiscent of 1993.
> Are unicorns coming back?
>
> len
>
>
> From: Priscilla Walmsley [mailto:priscilla@walmsley.com]
>
> Hi Len,
>
> Normally, min/maxOccurs are allowed on the choice element. Those 2 choice
> groups are invalid because they each appear as the child of a "group"
> element. XML Schema does not allow min/maxOccurs on the children of
> "group". Instead, you put min/maxOccurs on the _reference_ to the group, as
> in:
>
> <group ref="xxx" minOccurs="0" maxOccurs="6"/>
>
> Hope that helps,
> Priscilla
|