[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Marcus Carr <firstname.lastname@example.org>, Don Park <email@example.com>
- Date: Wed, 11 Jul 2001 08:17:01 -0500
Right. James's solution turns
cakes into puree. It liquifies the names and
after that, options go away.
XML is designed for a short haul timespan.
When you want to design for the long haul,
go back to the SGML parent and work from
Splintering XML doesn't bother me. It is
itself a splinter of the original.
If it is the delusions of history that bother
people, you have to accept the fact that a
well-made Persian rug will outlast XML by a
factor of ten at least.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Marcus Carr [mailto:firstname.lastname@example.org]
Don Park wrote:
> No, I did not mean that </> could be a start tag for an element named "/".
> Marcus, don't you think you are nitpicking over details which are best
> worked out after some consensus gathers behind James' proposal?
Sorry Don, please advise me when the appropriate moment arises for further
In the mean time, another concern is the fact that by allowing all
to be name characters, we forgo the possibility of sequestering a currenly
illegal character for a purpose similar to the way that the colon has been
used to represent a namespace. Are we now certain that we don't need to keep
any characters in reserve for the future? (We only got away with redefining
the colon because it happened early enough in the in the piece.) Would those
who use non-ASCII character sets feel obliged to reserve their own set of
characters for the same purpose? If so, the proposal would not eliminate the
problem, only make it very, very much smaller. Parsers would still have to
keep pace with languages... I suspect this is why Len feels that this is an
SGML problem - the easiest way for the parser to keep pace is to be provided
with a map of characters at processing time.