[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Historical I18n Note
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Sean McGrath <email@example.com>, firstname.lastname@example.org
- Date: Thu, 19 Jul 2001 08:22:16 -0500
From: Sean McGrath [mailto:email@example.com]
[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
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,
>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.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h