Lists Home |
Date Index |
- From: Joe Lapp <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 29 Nov 1999 00:03:11 -0500
I'm learning through the grapevine that some people of influence are opposed to the SML effort. I'm going to argue that provided SML ends up a subset of XML, as it should, the only conflict SML has with XML is the name. I walk through this step-by-step out of fear that I might leave someone with insufficient information to read between the lines.
I suspect the opposition is very comfortable with the idea that a system might source and consume only documents of a single document type. XML is after all a metalanguage for creating such document types.
I also suspect that the opposition is very comfortable with the idea that a system might source and consume documents belonging to a finite set of document types. I could have a finite set of DTDs defining these document types.
But suppose I have a system that sources and consumes only documents whose element type names are expressed in English. This is not hard to imagine and is probably quite rampant. But no finite set of DTDs can define this set of documents. Likewise, no finite set of DTDs can define the set of documents whose element type names are all letters or the set of documents whose elements don't use attributes. Yet if a system is allowed to select its document types, why can't it select an infinite subset of all possible document types? What if it's a tool that converts attributes to elements? Such systems should be allowed.
DTDs are not very expressive, but we can imagine a schema language that specifies where PIs are allowed and where comments are allowed, for example. XML allows these pieces everywhere, and my system might be able to parse them anywhere, but the higher layers of the system may not recognize them in certain places or may outright reject them. PIs there would be deceiving in application X, so let's not allow them. My domain-specific GUI can't represent comments there -- they'll get lost -- so let's not allow them. Maybe it's a tool for enforcing a way of commenting XML in accordance with company policy. These constraints happen, and there's no stopping them. Yes, the XML processor is required to report PIs (and may report comments) to the application, but no application is required to succeed if they are reported.
The XML 1.0 spec allows an application to accept and reject any subset of XML; it only makes demands of the XML processor that the application contains. I believe this is in full conformance with the spirit of XML as well, as it's only the parsing technology that it strives to make universal.
Yet if the application is going to reject that comment or that PI or that non-English element type name in the end, what difference does it make to the outside world whether it is the parser layer that makes the decision? Each application in a ring of applications exchanging XML is already beholden to conform to a particular schema or set of schemas, so it's already the business of this ring to decide what constitutes acceptable XML.
Provided that the SML effort yields a subset of XML, as it should, SML should end up being a label for a group of document types -- nothing more. One may then label an application as SML-compliant. Rings of SML-compliant applications may surface, but for most uses such rings will be further constrained to a finite set of document types. If we had a schema language of sufficient richness -- expressing name production rules and general syntactic layout -- we could even use it to express the SML class of document types.
What's wrong with defining classes of XML document types and restricting applications to using XML belonging to these classes? The notion sounds useful for much more than identifying the set of 'simple' document types. Is this not reasonable?
And maybe the SML audience can give a little by choosing a name that makes SML sound like a class of XML rather than an alternative to XML.
Joe Lapp (Looking for some good people to help design
Senior Engineer and build the Internet's business-to-business
webMethods, Inc. XML infrastructure. We are 100% Java.)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)