[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Historical I18n Note

• From: "Bullard, Claude L (Len)" <clbullar@i...>
• To: Sean McGrath <sean.mcgrath@p...>, xml-dev@l...
• Date: Thu, 19 Jul 2001 08:22:16 -0500

-----Original Message-----
From: Sean McGrath [mailto:sean.mcgrath@p...]

[Len Bullard] talking about the SGML Declaration
>Again, the Declaration is the ultimate escape hatch:

>I disagree with Len here.

You aren't the only one. :-)

>The SGML Declaration is not the ultimate escape
>hatch. It is a declarative syntax providing a finite
>amount of options for configuring the lexical side
>of an SGML parser. A finite set of dials that can
>be twisted.

True.  It is the escape hatch the standard provides, 
one that can be improved in the next revision of 
SGML with input from the community.  It's always 
good to preserve and improve options.

>If the configuration you want cannot be achieved
>by twisting the dials -- you are out of luck.

Yes.  If the ship sinks and you can't get to 
the escape hatch because someone welded it shut, 
you are outta chances.

>The ultimate escape hatch is *code* - always.

Sort of, even then, you have to count on the 
code support being there, or the willingness 
of the user to download the support.  Again, 
risks.

>The trick with declarative syntaxes is to mix
>asymptotic omniscience with humility - try and
>forsee what will be needed in terms of "dials" but leave
>an escape catch to splice in imperative code when
>your forsight is found wanting (which it will).

Yep.  Some people stay near the hatch and others 
risk working in the boiler room.

>Both extremes of the mix are unsavoury to the masses.
>SGML is an example of the former. Lisp is an example
>of the latter. 

SGML was designed in a different time for a different 
set of requirements.  It worked ok.  Now we have new 
systems, new requirements, and it needs redesign.  What 
has been learned in the XML products can serve as an 
important source of design requirements for a new version 
of SGML.  Of course, it remains a superset to these.

>XML does not solve this problem - it just
>moves it into other systems that then struggle with
>it afresh. XSLT for example:-)

Yes, just as those were being moved into DSSSL.  On 
the other hand, some see pureeing XML or adding yet 
more magic markers as the solution to the Blueberry 
problem.  That is fine for XML.  I think it is a design 
tradeoff the parent language will avoid.

As for NEL, IBM can seek alternatives in other 
forums.  They had a big hand in the creation of 
the parent standard and might want to reexamine 
their interests in light of those assets.  If 
XML is unserviceable, they have the alternative 
of deriving a new subset, perhaps even working 
with the SGML revision.

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

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

• Prev by Date: Re: Closing Blueberry
• Next by Date: Non-XML Solutions (RE: Closing Blueberry)
• Previous by thread: RE: Historical I18n Note
• Next by thread: XML under JDK 1.0
• Index(es):
  • Date
  • Thread