Re: [xml-dev] nextml

["Pete Cordell" <petexmldev@codalogic.com>]

Hi Amy,

Looking at this, would it be fair to say that your main concern is trying to 
fix namespaces, possibly not so much in the XML files themselves, but their 
usage in things like XPath?

Other than that, you look fairly content with XML 1.0 as it is.

Thanks,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

----- Original Message ----- 
From: "Amelia A Lewis" <amyzing@talsever.com>
To: <xml-dev@lists.xml.org>
Sent: Thursday, December 09, 2010 4:27 AM
Subject: [xml-dev] 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
>
> _______________________________________________________________________
>
> 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
>
>