[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: Tony Graham <Tony.Graham@ireland.sun.com>, email@example.com
- Date: Wed, 18 Jul 2001 14:25:26 -0500
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
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.
>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
>Yes, but do you want every XML processor to have to parse and act on
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
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
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.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h