[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SML

  • From: Paul Tchistopolskii <paul@q...>
  • To: Kragen Sitaker <kragen@p...>, xml-dev@i...
  • Date: Mon, 22 Nov 1999 17:12:46 -0800

decompress sgml


> 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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



  • References:
    • Re:
      • From: kragen@p... (Kragen Sitaker)

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.