[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Historical I18n Note
The theory if not the practice is that when we specify a system (eg, 1.0) from an international standard, we understand the intent of that standard and act within its definitions and that when we prove that the standard does not provide adequate definitions, we submit changes to the pending revision of the standard. The flaw in XML thinking is owing to the consortium's influence, SGML is dead and therefore not an asset to be used as needed, instead of, SGML is the parent standard of the XML specification and can be improved thus improving the standard capabilities of the XML product. >The syntax of the SGML Declaration as keywords and values separated by >whitespace was a design decision by SGML's designers. The main >argument that I used to hear against using SGML markup in the SGML >declaration was that you would need an SGML parser to bootstrap an >SGML parser. And now that we accept the PointyBracket is supreme over all others, that seems silly. I doubt it was in the day when the whitespace delimited format was dominant. That said, it would be interesting to see if a proposal can be made to the ISO working group for a revision of the SGML Declaration in light of current technology. >I'm not doubting that the full generality of the SGML Declaration's >character set definition mechanism is useful, I'm just doubting that >you'll see it implemented in every XML processor. So do I, but options are good to have. It is not unthinkable that XML is not the last of the SGML derivatives particularly if the owners of the product prove unresponsive to customer requirements. For that reason, the health of the parent standard is always of interest. In this case, the Blueberry and beyond Blueberry parties have an extra option. They won't take it but it is there. >Right now the SGML Declaration is in a format the you have to parse >with a hardwired parser. That hardwired parser has to recognise '<' >and '>' in the SGML Declaration because the Declaration is delimited >by them. I've never understood why the SGML Declaration isn't some >really limited SGML markup format. That would require a different >hardwired parser, but the SGML Declaration would have been in a form >that the people who use SGML were familiar with. <snip> >I contend that part of why the SGML Declaration is seen as so >unapproachable is that its format is so unapproachable. And if it is to continue to be an option, improving it is of use. That reads like a valid suggestion in light of current technology. > >> 3. Completely redefine the SYNTAX clause. Bryan provides > >> an example of an alternative syntax-reference character > >> set description for EBCDIC that changes the reference > >> concrete syntax. > > >That's what you'd have to do. > > It seems useful at the very least as the normative way to document the > differences. >Yes, but do you want every XML processor to have to parse and act on >that document? That depends. Currently XML processors don't have to act on a DTD or schema unless instructed to. The difference would be the Declaration would have to be processed if the Blueberry document were there and it would have to act early. On the other hand, this doesn't sound worse than the suggestions that the Blueberry parser doesn't pass a non-Blueberry document. Where is the cost worse? >> That might be worth changing. The URN is a name, so enabling >> it in the declaration should be viable. >Whether or not it's worth changing is a separate discussion to whether >or not XML processors should use SGML Declarations. It is a question as to where improvements to the SGML Declaration would improve their usability by XML processors. >Following the intent of the standard would be very lonely, I think. Which is why XML is a specification I guess. On the other hand, perhaps following a standard that is now out of date with the current technology simply says the standard is in need of deeper revisions. How many people care about DSSSL today? >That changed in time, and I doubt that many of the thousands of people >who've downloaded nsgmls ever analysed its System Declaration before >parsing their first document. I doubt half of the XML developers know what an SGML Declaration is, probably, about the same percentage of HTML users who knew why a DOCTYPE was in HTML. What is hardwired disappears from view, but that is precisely why hardwiring some information into systems works against the lifecycle of the information. Interoperability is only part of the markup story. It dominates in the web world because of decentralized systems, minimalized design with maximal implementation, the short lifecycles of the documents and the presbyopia of web design. >Nor would they have had to, since >nsgmls had capacities greater than you were allowed to specify in an >SGML Declaration. The capacities were obsolete. They should go away. >The System Declaration was only ever useful to a >fraction of a percent of SGML users, and now you want to require it >for the majority of XML users. I wish you luck. I don't think it has to be required. I think it is an option worth keeping where XML designs don't meet requirements. There are other options. One of them is to fix XML with respect to Blueberry, but you are sanguine that they all meet that requirement, yes? >I joined this thread because you gave half the story on >the SGML Declaration's character set definition and didn't mention how >well or badly those character set definitions were handled by the >available software. True, I didn't. On the other hand, no one mentioned how badly XML software would handle EBCDIC until IBM brought it up, or how many cultural assets would disappear unless XML were improved. The fault to be fixed is in XML. The means are all options. There are associated costs. Exploring the options has the side benefit of distilling information that might be of use in improving the parent standard to improve the options. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h
|
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
|