Cart
[Home] [By Thread] [By Date] [Recent Entries]
Good analysis. I think you only have to prove to tool makers they will sell more instances if they make the changes which simplify composition by base users. The question, can XML be easier is the same question Jean Paoli asked about SGML. Going in the direction of simplifying common tasks is seldom wrong as an evolutionary choice. It seems to me easing the syntax rules and making them more 'expressively" compatible with common programming language practice is a win because it doesn't limit expressiveness of the markup content. Rick is right about datatype assignment. Most of the hoops XML applications jump through look a bit tedious. I understand wanting more expressiveness there, but really in practice we're tracking the differences among Microsoft, Oracle, etc. XML as object notation has been tried. Unless parts of what a reasonably skilled professional user of the tools composes are as easy to compose as they would in other notations, then XML as more than a tree of well hung value pairs is limited by tool evolution. IOW, a baked parser is fine. Document the variations and let the spec sort itself out in its process time. The problem is getting the programmers at Microsoft, Google, Oracle, IBM and all points east to implement it in tools they considered tucked away for the night. So you want to find the programmers at those companies who endure the same tedium with XML. They will do the convincing. len -----Original Message----- From: Amelia A Lewis [mailto:amyzing@t...] Sent: Tuesday, December 07, 2010 9:34 AM To: xml-dev@l... Subject: nextml: some notes on instance requirements Heyo. Slightly different perspective. What are the requirements for instance documents, for a 'nextml'? Best Practice: Elliotte Rusty Harold and some others have been focussed on creation of a "profile" or "conformance class" or perhaps "collection of best practices" for XML 1.0. That is, every document in this nextml is a well-formed (and namespace-well-formed) xml 1.0 + namespaces in xml document. It seems to me that this requires no indication in an instance document, although an optional indicator might allow some processors to optimize. Non-breaking change: (for example) Michael Kay has proposed an alternative namespace syntax, that doesn't violate xml 1.0 without namespaces, and that could possibly be transformed into xml 1.0 + namespaces algorithmically. The tag minimization proposals might fit here (except for their tendency to produce ill-formed (well, the equivalent) documents in SGML days, suggesting that transformations would fail more often in these cases). It seems to me that for such cases, where the nextml instance document is well-formed xml 1.0, but would provide less information than it contains to existing xml 1.0 processors, unless a common/standard transformation were first performed, a new PI would be sufficient. Breaking change: several have been proposed in the past few days, from permitting nested comments, to establishing an equivalence between attributes and simple child elements (and more that I haven't remembered). Such instance documents wouldn't be well-formed XML 1.0. The version number in the XML declaration must be changed. It would be easiest to get agreement on a set of best practices (note: I said "easiest;" I didn't say "easy"). It could be done outside of a sponsoring specification organization. It doesn't interest me, much, but it seems to appeal to a number of people here. Non-breaking changes could also be hammered out outside of a specifying organization, and consequently might have a chance of producing results in less than a year. This is the path that looks most interesting to me, at the moment (in part because I think that proving the concept, via non-breaking changes, might encourage more serious consideration of a nextml at W3C). Breaking changes are going to be hardest, take longest, and meet most resistance. Lots of people (and organizations) with a stake already on the table, and with influence in the organization that owns XML specifications. As I said, I don't think that the process is likely to start until there are some interesting "non-breaking" type proofs of concept to encourage W3C. Me, I'd like to see the namespaces problem addressed. I'd *so* much like to see nested comments, but I doubt that we can get those without a spec revision. Amy! -- Amelia A. Lewis amyzing {at} talsever.com Did you exchange a walk-on part in the war for the lead role in a cage? -- Pink Floyd _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3301 - Release Date: 12/06/10
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
