- From: len bullard <cbullard@hiwaay.net>
- Date: Fri, 16 May 1997 21:58:35 -0500
- To: Andrew Layman <andrewl@microsoft.com>
- CC: "'w3c-sgml-wg@w3.org'" <w3c-sgml-wg@w3.org>
Andrew Layman wrote: > > Where they do become important is when XML is machine-generated as a > transport protocol by an automated process. For example, it is very > important to me to consider using XML as a format for getting results > back from database queries. They might be financial records, electronic > commerce records, purchase orders, etc. These are neither written by > humans nor meant to be read by humans. In many of these cases, the > volume of data is large, but is mainly short fields, so the overhead of > lengthy tags is pretty high relative to the basic data. I'm getting a > lot of pushback from database people regarding this point. They are very > concerned that we make it possible for them to be more economical in > their encoding. Accomodating their needs means opening up a whole > additional category of XML user. But an old category of SGML user. You are now discovering some of the reasons for SGML features which were tossed away for the ease of the DPH. This is the whole conundrum of XML. You are considering applications for which sensible applications of SGML are perfect, but seem to be slightly misinformed or unwilling to consider the parent standard. Smart designers look past the politics of standardization for the features they need and use them. Politicians, zealots, newbies and the *thought-impaired* use a standard simply because of its source. XML cuts both ways but a lot of effort has been expended to make sure it is compatible with SGML. Despite what you may have heard or believe, there are very good reasons for insisting on that. An SGML file can be made quite small and quite legal. A well-formed XML file is still just an SGML file you did not validate. The reverse may not be true; that is SGML's strength and XML's poverty. len bullard
Received on Friday, 16 May 1997 22:58:50 UTC