RE: [xml-dev] nextml: some notes on instance requirements

["Len Bullard" <cbullard@hiwaay.net>]

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@talsever.com] 
Sent: Tuesday, December 07, 2010 9:34 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] 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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
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