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

Re: Feeler for SML (Simple Markup Language)

• From: "Michael Champion" <Mike.Champion@s...>
• To: "xml-dev" <xml-dev@i...>
• Date: Thu, 11 Nov 1999 11:39:13 -0500

----- Original Message -----
From: Leigh Dodds <ldodds@i...>
To: xml-dev <xml-dev@i...>
Sent: Thursday, November 11, 1999 10:26 AM
Subject: RE: Feeler for SML (Simple Markup Language)



>
> Well isn't your contract between your and Dons processors going to be
> the 'protocol' for your application. Can't that protocol just say
> "We're using XML, but without any attributes, and...". You've still got
> to define the message formats so define them without recourse
> to PIs, entities, attributes, etc, etc

That's a good point ... I guess it's a bit hard to make a case for something
like SPL on the typical Internet platform with a big server and a powerful
browser and a built-in standard XML processor.  And perhaps this can be
addressed at the level of protocols and schemas, not the meta language
itself.  Nevertheless, it still seems useful to explore the idea of defining
a class of XML-ish schemas, protocols, and the tools that can process them
by defining a subset of XML itself that is optimized for situations where
entities, notations, validation, etc. are inappropriate.

I for one am most interested in its applicability to light client, low
bandwidth environments such as phones or PDAs ... and extremely high
transaction volume messaging or database applications.  Someone on this list
asked yesterday for ideas about using XML in an application that required
something like 100MB of data to be analyzed and stored in a second. That is
probably WAY beyond the capabilities of any current XML system I know of,
but is the KIND of scalability that the largest enterprise applications will
require soon, if they don't today. (Witness the performance and reliability
problems that various wildly successful e-commerce sites are having for an
example of the importance of architecting scalability in at the beginning of
a project ...).

XML as we know it has numerous features -- see Don's list -- that seem much
more applicable to traditional SGML-ish document processing applications
than enterprise-scale (or low footprint/bandwidth) data processing
applications.  It appears to me that XML and its current tools have
*adequate* responses here, e.g. your example of dynamically loading
entity-resolving code when I get a message that some *$#@^% put an external
entity reference in ;~)   On the other hand, I'm not at all convinced that
XML now has the OPTIMAL response here. It would appear to me that there is
considerable potential -- and I would want to see performance data
supporting this notion before investing heaviliy in it -- for improving the
scalability of data XML processing tools by using a subset of the spec that
doesn't have the SGML text processing legacy in it.


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: Feeler for SML (Simple Markup Language)
    • From: Leigh Dodds <ldodds@i...>

• Prev by Date: Re: external parsed entites (was: A unique ID question ?)
• Next by Date: Re: external parsed entites (was: A unique ID question ?)
• Previous by thread: RE: Feeler for SML (Simple Markup Language)
• Next by thread: RE: Feeler for SML (Simple Markup Language)
• Index(es):
  • Date
  • Thread