Re: A17: keep or drop entities?
R A Milowski wrote:
> > After reflection, I think we should keep external entities. FPIs and
> > FSIs should be syntactically reserved, with pointers to the relevant SGML
> > material as an explanation, but they themselves should not be part of XML
> > 1.0. This _commits_ us to an XML 2.0. If such a commitment is not
> > plausible, we should bite the bullet and put it all in now.
I think the commitment to XML 2.0 is invitable if we want to
stick to the schedule and get a revenue stream started to
support the effort. The most serious mistake we can make
is to treat this as an academic exercise and hope that
freeware will appear from the universities. The WWW is
a wheel in motion, going somewhere fast, and to influence
that direction in any way at this late date, we must run
alongside until we can get inside. So, it is not possible
to consider 1.0 as a complete XML. It is a version designed
to get products in the pipeline of framework handlers.
Once a sustainable product line is established, it is possible
to consider features that add power/complexity.
Don't try to do it in a day.
> After being quite silent for awhile, this is a statement I could
> agree with on external entities. Creating generic publishing systems
> for use over the web is going to demand more complex features. These
> features are not going to be trivial to solve and implement--but they
> will not be impossible either.
True, but if the bar is raised too high, too many jumpers fail
on the first try and the sport is considered harmful or *only
for the gifted*.
> At some point it time we are going to have to say: "We've done all the
> easy stuff, and its not enough to solve our problems."
True. Let's figure out what the problems are by experience.
> We should outline what we think should be in or considered in 2.0 if
> we are not allowing these things now. We don't want to go through the
> same discussion about character encodings, RS/RE, etc. again if we
> aren't going to change them in 2.0. We should have an additive process.
I agree, Alex, but I have the VRML 1.0/2.0 experience in mind as
I watch this process. From a standing start, they got products
in the pipeline less than three months after spec completion.
They did not start fresh; they hacked Open Inventor ruthlessly,
taking away features until they had an initial design that
could be built quickly, would work in the Internet environment,
could be supported by existing code (e.g, Renderware).
In VRML 2.0, the same process was repeated. We knew we needed
motion and extensibility. Frame interpolators were put in
the language and protos (internal and external). In 2.0,
the syntax was improved. To get this, SGI had to sign up
to provide a reference implementation free and clear of
encumbrance. I believe such requirements may be necessary
for complex features one wants to add to XML. A script node
is included, but no script language is required. An external
interface is being outlined now. VRML 2.0 must be the last
major shock to the syntax because too much software had
to be rewritten. We might better that achievement, but
2.1 and up to 3.0 are considered improvements to capabilities
such as the scripting and multi-user support.
So, while I agree with what you are proposing, I expect that
it will be hard without experience with 1.0 to precisely
define the problems. We may want to do as the VRML community
did, and provide a list of capabilities we want to have in
place at each version level. Goals must ensure stability
of product development. I also keep the HyTime experience
in mind. IMO, it could have achieved more if we had
spec'd a little, implemented a little, fielded a little,
and spec'd a little more. It might have taken just as
much time, but it would have had a product line and
revenue stream in place when completed.