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.

Len Bullard
Lockheed Martin

Received on Friday, 18 October 1996 13:18:34 UTC