RE: Historical I18n Note

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

The theory if not the practice is that when we specify a 
system (eg, 1.0) from an international standard, we understand 
the intent of that standard and act within its definitions 
and that when we prove that the standard does not provide 
adequate definitions, we submit changes to the pending revision 
of the standard.   The flaw in XML thinking is owing to the 
consortium's influence, SGML is dead and therefore not 
an asset to be used as needed, instead of, SGML is the 
parent standard of the XML specification and can be improved 
thus improving the standard capabilities of the XML product.

>The syntax of the SGML Declaration as keywords and values separated by
>whitespace was a design decision by SGML's designers.  The main
>argument that I used to hear against using SGML markup in the SGML
>declaration was that you would need an SGML parser to bootstrap an
>SGML parser.

And now that we accept the PointyBracket is supreme over all others, 
that seems silly.  I doubt it was in the day when the whitespace 
delimited format was dominant.  That said, it would be interesting 
to see if a proposal can be made to the ISO working group for a 
revision of the SGML Declaration in light of current technology.

>I'm not doubting that the full generality of the SGML Declaration's
>character set definition mechanism is useful, I'm just doubting that
>you'll see it implemented in every XML processor.

So do I, but options are good to have.  It is not unthinkable that 
XML is not the last of the SGML derivatives particularly if the 
owners of the product prove unresponsive to customer requirements. 
For that reason, the health of the parent standard is always of 
interest.  In this case, the Blueberry and beyond Blueberry 
parties have an extra option.  They won't take it but it is there. 

>Right now the SGML Declaration is in a format the you have to parse
>with a hardwired parser.  That hardwired parser has to recognise '<'
>and '>' in the SGML Declaration because the Declaration is delimited
>by them.  I've never understood why the SGML Declaration isn't some
>really limited SGML markup format.  That would require a different
>hardwired parser, but the SGML Declaration would have been in a form
>that the people who use SGML were familiar with. 
<snip>
>I contend that part of why the SGML Declaration is seen as so
>unapproachable is that its format is so unapproachable. 

And if it is to continue to be an option, improving it is of use.  That 
reads like a valid suggestion in light of current technology.

 > >> 3.  Completely redefine the SYNTAX clause.  Bryan provides 
 > >> an example of an alternative syntax-reference character 
 > >> set description for EBCDIC that changes the reference 
 > >> concrete syntax.
 > 
 > >That's what you'd have to do.
 > 
 > It seems useful at the very least as the normative way to document the
 > differences.

>Yes, but do you want every XML processor to have to parse and act on
>that document?

That depends.  Currently XML processors don't have to act on a DTD or 
schema unless instructed to.  The difference would be the Declaration 
would have to be processed if the Blueberry document were there and 
it would have to act early.   On the other hand, this doesn't sound 
worse than the suggestions that the Blueberry parser doesn't pass 
a non-Blueberry document.   Where is the cost worse?

>> That might be worth changing.  The URN is a name, so enabling 
>> it in the declaration should be viable.

>Whether or not it's worth changing is a separate discussion to whether 
>or not XML processors should use SGML Declarations.

It is a question as to where improvements to the SGML Declaration 
would improve their usability by XML processors.

>Following the intent of the standard would be very lonely, I think.

Which is why XML is a specification I guess.  On the other hand, perhaps 
following a standard that is now out of date with the current technology 
simply says the standard is in need of deeper revisions.  How many people 
care about DSSSL today? 

>That changed in time, and I doubt that many of the thousands of people 
>who've downloaded nsgmls ever analysed its System Declaration before
>parsing their first document.  

I doubt half of the XML developers know what an SGML Declaration is, 
probably, about the same percentage of HTML users who knew why a 
DOCTYPE was in HTML.  What is hardwired disappears from view, but 
that is precisely why hardwiring some information into systems 
works against the lifecycle of the information.  Interoperability 
is only part of the markup story.  It dominates in the web world 
because of decentralized systems, minimalized design with maximal 
implementation, the short lifecycles of the documents and the  
presbyopia of web design.

>Nor would they have had to, since
>nsgmls had capacities greater than you were allowed to specify in an
>SGML Declaration.  

The capacities were obsolete.  They should go away.

>The System Declaration was only ever useful to a
>fraction of a percent of SGML users, and now you want to require it
>for the majority of XML users.  I wish you luck.

I don't think it has to be required.  I think it is an option 
worth keeping where XML designs don't meet requirements.  There 
are other options.  One of them is to fix XML with respect to 
Blueberry, but you are sanguine that they all meet that requirement, yes?

>I joined this thread because you gave half the story on
>the SGML Declaration's character set definition and didn't mention how 
>well or badly those character set definitions were handled by the
>available software.

True, I didn't.  On the other hand, no one mentioned how badly 
XML software would handle EBCDIC until IBM brought it up, or 
how many cultural assets would disappear unless XML were improved. 

The fault to be fixed is in XML.  The means are all options.  There 
are associated costs.  Exploring the options has the side benefit 
of distilling information that might be of use in improving the 
parent standard to improve the options.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h