Re: Update on namespaces

David G. Durand wrote:
> 
> >All redefining the DTD into uselessness does is increase the
> >urge to abandon XML work and return to fixing SGML.  That
> >process will be more rational than one in which faceless, nameless
> >wordless entities set the rules, the tenor, and the outcome.  Nyet.
> 
> I don't really agree here. I think SGML will _not_ fill the role XML _may_
> fill, so I don't think this is an option, at least for me.

It may not be a personal option; I suggest it could become a trend.
This isn't a technical issue; it is a political one.  We cannot 
have a standards process built on faceless policy.  That is not a 
way to build trust and without trust, there will not be progress.  
I am not naive.  I understand how standards are written in many 
cases.  It is for precisely that reason that I prefer open 
noisy debate to closed door meetings of like minded and 
financially obligated conspirators.

Call that paranoid if you like;  I prefer laws written by the elected.

As for the role SGML or XML may fill, SGML can be changed and XML 
can fail to be adopted.  These are also possibilities.  I wouldn't 
be too smug out there.  There are still only two viable commercial 
vendors of Web browsers.  It isn't a pretty or terribly open market.
As predicted, even that number may thin.
 
> >The XML reference to ISO 8879 must be normative to prevent precisely
> >this kind of bad judgement and unregulated process.
> 
> I still disagree with this. A normative reference turns 8879 into mandatory
> reading for implementors, and implies that _if_ there's a hole in the XML
> spec, then 8879 may automatically be invoked to clarify things 

No.  It says where XML uses SGML as the intellectual basis of its 
construction, it is legally obligated to maintain that inviolate.  It
becomes 
an issue of conformance testing after that instead of the SGML Way.  
The lack of the first hobbled SGML systems, but the presence of the 
second nailed it to the cross with a vengeance.

Beware The Spirit of XML.  Religion ain't computer science.

> -- and I
> don't think that XML can assume that 8879 will give the best solution to
> unanticipated problems. 

I don't think we can assume the W3C and the ERB can either.
We're all just chickens, David, and anyone on any given 
day can lay a big one.

> The XML standard must be free-standing -- It's up
> to us to make sure that it is.

I agree absolutely that it must be freestanding.  I disagree that a
normative 
reference prevents this.  A normative reference makes it difficult to
step 
up and say, "XML just looks like SGML, but it isn't really so we don't
have 
to worry about too many legal niceties as we change it".  It also puts a 
lot of pressure on WG8 to keep the parent standard moving.  Some of you 
have publically and privately expressed your disbelief and lack of faith
in 
WG8's judgement and ability.  I think the SGML/XML negotiations prove
otherwise.

No apologies folks, but given a choice between the inexperience of the
W3C and 
the slowness of ISO, I prefer the organization with fifty years of
experience 
and a crutch.  It is predictable.  It just needs help crossing against
the light.
 
> We can't use 8879 as a crutch, but have to resolve our own problems here. I
> may be arguing a conservative line on this issue, but it's not because I
> believe that we _shouldn't ever_ extend on 8879, but that we had better
> _understand_ any extensions we do, and _all_ the implications.

We aren't an island.  We are in the majority, the SGML community trying 
to create a subset of SGML that will be viable in a very large
distributed 
computing network that already have more crutches than it needed.

As for understanding extensions, practice makes perfect.  I suggest 
that XML be a lot simpler before it gets into practice.  The Suzuki 
method works for kids and WebHeads.

Len Bullard

Received on Thursday, 19 June 1997 22:36:07 UTC