Re: Feeler for SML (Simple Markup Language)
----- 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...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format