OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: SML answers for SML problems

[ Lists Home | Date Index | Thread Index ]
  • From: Hokkun Pang <hpang@flycast.com>
  • To: 'Don Park' <donpark@docuverse.com>, xml-dev@ic.ac.uk
  • Date: Fri, 12 Nov 1999 07:25:15 -0800

duh, can't you come up with a better name?
SML is short for Standard Meta Language, which has be around for quite some
time
and holds a respected place in the computer science field.

> -----Original Message-----
> From:	Don Park [SMTP:donpark@docuverse.com]
> Sent:	Friday, November 12, 1999 6:03 AM
> To:	xml-dev@ic.ac.uk
> Subject:	SML answers for SML problems
> 
> There were many points raised in the initial discussion of
> the SML idea:
> 
> 1) Smaller and faster
> 
> I think everyone can agree that SML parsers will be smaller
> and faster than XML parsers due to removal of features.  What
> remains controversial is whether the difference is significant
> enough to justify SML.  Since we do not have SML parsers to
> compare XML parsers with, we are left with only extrapolations
> and guessworks.
> 
> My assessment is that the difference is not significant for
> general XML applications.  However, the difference is important
> for XML applications that places a high premium on size and/or
> speed.  On appliance-level devices, even 5K difference in size
> translates to significant manufacturing cost increase because
> memory size does not increase in friendly increments.  On network
> routers and proxies, even a few microseconds delay can mean
> significantly reduced load capacity.  There are no talk of
> 'documents' on these type of applications.
> 
> 2) Simpler and easier
> 
> Based on my experiences in 'spreading the XML religion', I
> find that XML is easy to learn but it is hard to learn
> completely.  Key ideas behind XML is strikingly simple yet
> most people get confused by things like DTD, PI, notation,
> comment, entity, XML declaration, whitespace rules, character
> encoding, etc.
> 
> One of the goals for SML should be:
> 
>     SML is what people think XML is.
> 
> By people, I mean the engineers understand the key concepts
> behind XML but have not yet been spoiled by the hairy details.
> SML should fit the mental model of XML people build when they
> first hear about XML.
> 
> I believe that an engineer can not use a tool fully unless
> he/she understands the tool completely.  Perhaps it is a
> peace of mind, perhaps it is confidence.  Whatever the reason,
> it is important that there is a clear mental picture of the
> tool and its capabilities.  Having a clear spec is great but
> having to refer back to it frequently is not good in my book.
> 
> SML will be simpler and easier to learn completely.  Question
> is whether there is truely a need for simpler and easier XML.
> 
> 3) Data versus Documents
> 
> A good part of XML 1.0 is designed to address document
> processing problems.  Those parts fails to apply when XML data
> exists only in transit (WebDav, XML-RPC, SOAP), has no end
> (continuous broadcast), or is sent one-way only.  While the spec
> for such applications might list the unsupported features of XML,
> I believe it is easier to just say the spec uses the SML subset.
> 
> 4) Friend or foe?
> 
> Is SML a friend or foe of XML?  Many folks brought up this
> question either directly or indirectly.  I happen to think
> SML will eventually help rather than hurt adoption of XML but
> the media might have a field-day with SML vs. XML articles.
> 
> My thought at this point is that SML is needed by a subset of
> the XML community.  Creating a subset of XML for subset of XML
> community seems like a reasonable thing to do.
> 
> Best,
> 
> Don Park    -   mailto:donpark@docuverse.com
> Docuverse   -   http://www.docuverse.com
> 
> 
> 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)

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)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS