Lists Home |
Date Index |
- From: Paul Tchistopolskii <email@example.com>
- To: Kragen Sitaker <firstname.lastname@example.org>, email@example.com
- Date: Mon, 22 Nov 1999 17:12:46 -0800
> Paul wrote:
> > Kragen wrote:
> > > I think it would be very nice, from a processing point of view, to have
> > > an XML variant that didn't have CDATA sections or DTDs (although entity
> > > definitions are useful!).
> > 1. Why entities should live in the core, if one can use
> > any macroprocessor to get *more* flexible functionality?
> > 2. How often do we need entities outside the DTD's ?
> Well, I think it's important to be able to include (a) < and & and (b)
> characters outside my charset.
Agree ... there is some need in #defines in .c files, but
mostly they are located in .h files ;-)
I still think that macroprocessor could live outside the core
( even macroprocessor is a handy thing ) - I think it may
result in better design, better documents e t.c.
> > > I suspect CDATA sections are hard to live
> > > without if you're writing XML documents about HTML or XML, though.
> > Let us have <CDATA> element ? I think up to 3-5 elements with
> > 'hardcoded' semantics will not cause a big problem.
> > I think it is not a big problem in traditional languages
> > to use reserved keywords to avoid function names like
> > for() or if() ;-)
> Interesting idea. But it would be just as hard to process as the
> current ]]> kludge; what is the benefit?
It's all very subtile, of course, but if we could live with
3-5 'predefined' elements +
it could be easier to learn and to remember the
entire thing, I think.
To be honest, I don't remember the format of
*all* the possible kludges I have to learn
during my life. Actualy I don't understand why
I have to learn many of those kludges.
Because 'clean' solution makes some
language purist happy ? What is "clean" ?
It's the issue of taste, I think.
I agree that the way it goes is that programmers
become integrators. If talking about the integration
it's better to have no kludges than to have
SML could become the *extremely* clear
glue. With 3-lines length specification and
trivial filters to/from XML turning
CDATA element into CDATA kludge,
for example. ;-)
If SML has only elements , comments and
characters - one could easy replace
<tag_number_1> with <1> on the server,
then decompress <1> with <tag_number_1>
on the client with *extremely* trivial ( short )
code. In any language, In one day. Don't think
it could be done with XML that easy.
Keeping kludges will make in a *bit* more
messy, but sometimes it counts, so why
not dropping everything that could be
dropped ? ;-)
Also, it is easier to learn and to remember <CDATA> tag
than CDATA kludge. Don't you agree ?
However, I think that CDATA should be killed, if
compatibility with XML is the unavoidable
requirment ( and I think it's better to saticfy
such a requirment ).
After CGI and HTML practice, escaping suspicious
charachters with ( predefined and hardcoded ) entities
is now OK.
> > However, this suggestion kills compatibility with XML.
> But not SGML :) :)
> > It's why I think that SML vs XML is very similiar to
> > XML vs SGML.
> > At some point it would be easier to break the
> > compatibility than to support legacy. As far as I
> > understand, exactly that thing happened with
> > XML vs SGML.
> . . .but XML is a subset of SGML.
Legacy, legacy ...
Actualy there is a *huge* work to create XML-based
*framework* - I can't belive one developer could create
it even using existing components.
The entire 'lite' SML-based framework could be written
by one person from stratch and with some filters to / from XML
( to / from SGML ) ( or without such ) it could utilize existing
XML / SGML tools
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)
- From: firstname.lastname@example.org (Kragen Sitaker)