Re: Revised SGML Declaration for XML 1.0

 
From: Paul Grosso <paul@arbortext.com>

> I can't decode all the numbers given for the name start characters,
> but from the comments below, it looks like you've added _ and : to
> name characters but not namestart characters.

I don't know what they decided.  I think the WG is definitely in favour
of ":" now, from recent comments.  And I think "_" is only sensible,
especially since we allow CENTER DOT and others!

> Now this is precisely what I want, but my understanding was that the
> ERB decided to add _ and : to namestart characters too.  (Why?  I see
> no reason to want to add _ or : to namestart characters, and it just
> so happens some tools [e.g., Adept] make use of an initial _
character
> to denote internally reserved names, so at least for the present, we
> will not be allowing _ as a namestart character.)  I'd be pleased to 
> hear I'm wrong and _ and : are NOT allowable namestart characters,
> but I wonder if someone can confirm the current decision.

I automatically didn't add _ as a namestart, because of Adept tools :-)

And I think it is premature to add ":" as a namestart, because then
people will use it with some namespace minimization conventions in
mind.  
I think that the only namespace convention that people should use 
at the moment is ISO 9070 style "::" qualifiers with no name
minimisation:
so  ::table  would not be valid, but "HTML::table" and
"SO::CALS::table" 
would be.

As far as I know, apart from Bert Bos's comments on case, this 
SGML declaration is relatively free from contraversiality, if 
you buy into native language markup in the first place. 

In the only area that is contraversial (spaces as SEPCHARS) we can 
always relax the rules if they are found unworkable (Gavin :-). 
I have put the extra characters into a convenient position to
allow people to uncomment them and make them SEPCHARS for the
purpose of getting a parsing document to allow corrections.
And I put in a recommendation that naughty types of spaces are
a validity error, rather than a WFness error.




Rick Jelliffe

Received on Friday, 27 June 1997 14:24:34 UTC