xml-dev - Re: SML

[Paul Tchistopolskii <paul@qub.com>]

> 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 
only :

elements + 
3-5 'predefined' elements  +
comments 

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 
some. 

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 

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)