[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

nextml

  • From: Amelia A Lewis <amyzing@talsever.com>
  • To: xml-dev@lists.xml.org
  • Date: Wed, 8 Dec 2010 23:27:18 -0500

nextml
Heylas!

Well, I've read a bunch of interesting web pages and proposals.

For me, anything that requires W3C to jump on board (in order to permit 
"<?xml version="!1.0" ?>") is ... *now* ... a non-starter.  I've 
participated in W3C working groups.  *Time*.

Conversely, anything that is a "best practice" for XML 1.0 (all 
conforming documents can yield full information in current 
namespace-aware parsers) is also a non-starter.  *yawn*  I might 
encourage people to write documents that way, but I can't get excited.

The "sweet spot," so far as I am concerned: a revision that can be 
supported in current processors via simple transformation, but that 
would parse, with information loss (or failure to load in 
namespace-required applications) in current processors and parsers.

What fits?  Well, Michael Kay's namespace proposal, or a variant.  The 
critical bit: every element has a "fully qualified name" and 
potentially a contextually-defined abbreviated name.  Comment nesting 
sort-of qualifies (a clever transform could make the nested comments 
not match the 'comment' production; the problem is that without the 
transform a document with these comments would be ill-formed).  I've 
seen a number of "only UTF" comments, and I think that they're rather 
western-centric, so I'm thinking "no," there (if someone whose native 
language *isn't* west european proposes it, I might rethink).  Removing 
DTD?  Well, if it's tied to pre-defining a richer set of entities, 
perhaps--or provide a non-DTD entity definition mechanism (don't like 
entities?  So what?  I think they're valuable).  On the other hand, a 
less-horrible means of distributed authority for vocabularies would 
make namespaces a dead letter, and possibly revitalize DTDs (I can't 
help but think that RNG is a better solution, though).

Remove mixed content?  No.  Provide "simple types"?  No.  No one can 
agree on them (I should publish DRVL, even though I haven't got the 
time to do the proof of concept implementation).  I knew folks on the 
original XML Schema Working Group; that spec is so difficult in part 
because it had to satisfy so many different interests.  Something like 
DRVL+FRVL might provide simple typing + extensibility, but then, it's 
possible that I'm simply overestimating a pet project.  Remove CDATA?  
Ambivalent.  It might help the parser writers, but who cares, at this 
point?  They already deal with it.  Add minimization (simplified 
end-tags)?  Moderately opposed; I understand from the grey-haired SGML 
types that this was a major, perhaps even primary source of bug reports 
and support requests.

Keep namespaces and impose restrictions on where they can be defined?  
No.  First, it creates a distinction between documents and fragments 
that is going to produce tons of problems; second, the fundamental 
design of namespaces in xml is broken and acknowledging that is the 
first step to solving the multiple-vocabulary problem.  I suppose I 
won't be terribly interested in *any* nextml that doesn't take on the 
namespace morass effectively--mind you, *I* can use the damned things 
with a fair degree of facility.  I just can't get other people up to 
speed effectively, unless they're very strongly motivated.  That 
shouldn't be necessary, in my opinion.

I offer this because we seem to be approaching the end of the "produce 
ideas" point, and are entering the "choose sides" phase.  Where I fall: 
if we can produce, in less than twelve months, a specification that 
allows an instance document to specify a small external transform that 
could then allow the document to be handled by current APIs, that can 
potentially provide enhanced results for new APIs, and that is easier 
to explain (apart from the opaque "put this PI right after the XML 
decl" bit) than current stuff, I'm on board.  If it's just best 
practices (no indicator required) ... meh.  If it's XML 1.0++ ... gods, 
spare me--prove something first.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
About the use of language: it is impossible to sharpen a pencil with a 
blunt axe. It is equally vain to try to do it with ten blunt axes 
instead.
                -- Edsger Dijkstra

  • Follow-Ups:
    • Re: nextml
      • From: "Pete Cordell" <petexmldev@codalogic.com>
    • Re: nextml
      • From: Liam R E Quin <liam@w3.org>
    • Re: nextml
      • From: Michael Sokolov <sokolov@ifactory.com>
    • Re: nextml
      • From: Uche Ogbuji <uche@ogbuji.net>
    • Re: nextml
      • From: Kurt Cagle <kurt.cagle@gmail.com>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.