Re: [xml-dev] nextml

[Kurt Cagle <kurt.cagle@gmail.com>]

Amelia,

I still think that sequences play into this. One of the problems that I think a lot of people on this list forget about JSON is that:

[{"foo":"a","bar","b"},{"bat","c"}]

is valid JSON. Perhaps something as simple as saying:

(<root><foo>a</foo><bar>b</bar></root>,<root><bat>c</bat>)

is valid NextML would go a long way towards solving the serialization issues. Using XQuery notation to describe XML might be cumbersome at first glance:

(element root {(element foo "a",element bar "b")},element bat "c")

might not seem like a huge improvement, but if you incorporated some minor change mappings in XQuery:

*foo{"a"}  == element foo "a"

*foo:bar{"b"}  == element foo:bar "a"

*{*bar{5}) == element root {element bar {5}}

then you can in fact represent an XML document using XQuery notation just fine:

(*{*foo{"a"),*bar{"b"}},*{*bat{"c"}})

cf.

[{"foo":"a","bar","b"},{"bat","c"}] for JavaScript

vs.

(<root><foo>a</foo><bar>b</bar></root>,<root><bat>c</bat>) for a sequence of XML.

This would require a minor change in XQuery, no changes whatsoever to the XML spec, but on the other hand could be used to give you a compact expressiveness that rivals JSON - and what's more could be translated fairly cleanly into JSON notation.

Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project

On Wed, Dec 8, 2010 at 11:27 PM, Amelia A Lewis <amyzing@talsever.com> wrote:

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