RE: Historical I18n Note
-----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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format