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

Re: SGML, XML and SML

• From: Paul Tchistopolskii <paul@q...>
• To: Don Park <donpark@d...>, xml-dev@i...
• Date: Mon, 22 Nov 1999 13:22:56 -0800

I think that SML vs XML is *very* similiar to
XML vs SGML.

XML exists because SGML has beed
considered to be 'too hard'  for learning and
'too heavy'  for placing into thin client. Right ?

SML could appear because actualy now
XML  *could* be considered to be 'too hard'
and 'too heavy'. Even not talking about the
namespaces.

SML proposal is nice.

Is there a URL keeping  the 'latest SML specification
draft'  ?

The funny thing is that after simplifying the XML
itself, next steps could ( would ) be:

1. Simplify SAX  1.0 ...

...  not talking about some complex processing ....
if just copying *unchanged* XML file  incuding
comments, and references to external ( missing)
DTDs from input to output  with SAX 1.0 ...

Creating fake EntityResolver... Using proprietary
APIs to keep comments and CDATA ( and
not every XML parser has such an API!) ... well ..
Was it  <A></A> or just <A/> ?

Such a mess...  Unfortunately, to me
SAX2 is not an answer, because it makes
things more complex ( yes,  it's because XML
gets more complex, but if starting with SML ... ;-)

2. Simplify XSLT. Just to make it easy to embed
XML + XSL processing into some client with small
memory.  ;-)

Actualy, the question about the memory is not that
simple. It sometimes comes to 'java or not java'.
'Java or not java' is a result of many things including
personal preferences of some well-known
developers. I mean " it is java because it is hard to
re-invent it and the preson who invented it - he likes
java ".

SML-based *tools*  have bigger probability to
get implemented by wider range of developers.

3. Simplify DOM ,  XQL ( or XML-QL ) e t.c. e t.c.

I'm not saying that SML *requires*  those
changes ;-) I'm saying that SML appearance
could have *such* an impact on XML ( like XML
appearance killed SGML, even at the beginning
I think nobody was thinking to kill SGML with
XML ? Or the idea was to kill SGML ?

The more I think about SML ....

... validation and entities could go away  from
the core ...  They are optional and could be done
with (optional) levels of processing.

Why should one place macroprocessor ( SYSTEM
and entities in fact *are* just macroprocessor
instructions ) into the *core* ?

What's wrong with m4 ? ;-)

OK ...  OK ... Let's face it. XML could be considered
to be bloated ( maybe a bit - but it counts, if we'l
take into account that XML is the *core* and
everything else ( XSLT, XSLQL, DOM e t.c.) is
based on the core ).

XML is much simpler  than SGML, but it still is
not as simple as it could (?) be.

I think there are some developers  who want
*very*  weak DTD-based validation and weak
macroprocessor  to reside in the core. But I'm also
sure that there are some other developers who
want strong ( Yacc-based ) validation on server side,
strong macroprocessing on server side and
*then*  efficient SML-based client *not*  bloated
with some useless  features. ;-)

Rgds.Paul.

> Tim Bray wrote:
> >And SML must not claim, explicitly or implicitly, to "be XML".
>
> I think this condition can be met.  We will make it clear that:
>
> SML is a subset of XML and is not to be considered, in any sense,
> as conforming to the full XML 1.0 specification.
>
> If you have better wordings, I'll be obliged.  It is not my
> intention to sabotage XML in-flight.
>
> Best,
>
> Don Park    -   mailto:donpark@d...
> Docuverse   -   http://www.docuverse.com
>
>
> 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...)
>


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

• Follow-Ups:
  • RE: SGML, XML and SML
    • From: "Don Park" <donpark@d...>

• References:
  • RE: SGML, XML and SML
    • From: "Don Park" <donpark@d...>

• Prev by Date: Re: Grafting DOM on a C++ XML parser?
• Next by Date: RE: What is a document?
• Previous by thread: RE: SGML, XML and SML
• Next by thread: RE: SGML, XML and SML
• Index(es):
  • Date
  • Thread