[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] XML Redux
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: liam@w3.org
- Date: Tue, 15 Feb 2011 16:29:41 -0500
Liam,
One of the keys though is to notice the evolution through this and the next post on the thread, and the point that I've tried to emphasis - the notation is largely immaterial, the data model is not.
Any notation that involves the use of non-tagged delimiters is going to run into the Lisp dilemma of too many parentheses. Personally, I prefer working with XML syntax myself because it is usually much easier to determine when you have a misplaced ending tag (as my example illustrates, even if unwittingly), but even if we use a more XMLish notation, it's still necessary to recognize that angle-bracket serialized XML doesn't have a formal concept of lists or sequences that aren't nodal in nature. XQuery does. The syntax differs, but
html: (head: (title: (This is the top title) link: (@rel:
(stylesheet) @href:(my.css)) body: (h1: (This is the page
title) p:(This is a b: (test).)))
and
element html {
element head {(
element title {'This is the top title'},
element link {
(attribute rel {'stylesheet'},
attribute href {'my.css'})
}
)}
element body {(
element h1 {'This is the page title'},
element p {('This is a ',element b {'test'},'.')}
)}
}
and
<html>
<head>
<title>This is the top title</title>
<link ref="stylesheet" href=""my.css"/>
</head>
<body>
<h1>This is the page title</h1>
<p>This is a <b>test</b>.</p>
</body>
</html>
are all isomorphic, with the first in a "terse" notation, the second example given as an XQuery expression that is essentially a one for one equivalent, and the third being the angle bracket notation.
Is it legible? Good question? If you take JSON and remove the white space, is it legible? Personally, no, it's not. Is it more compact? Marginally, though EXI is even more compact. Is it in a format that may be more familiar to non-XML developers, while still being useful to XML types? Quite possibly, especially if your goal is expressing a super-language that can encompass both JSON and XML while not necessarily limiting either.
The point I'm trying to make here is that this is a superior language - it's that once you move away from a supported XML (as Michael's original post did) and start asking what the best underlying data model is for representation that can handle both, I'd say that XDM is a good candidate; after that, it's quibbling over characters.
Kurt Cagle
Member and Invited Expert
XForms, HTML Working Group
World Wide Web Consortium
443-837-8725
On Tue, Feb 15, 2011 at 3:36 PM, Liam R E Quin
<liam@w3.org> wrote:
On Tue, 2011-02-15 at 13:01 -0500, Kurt Cagle wrote:
> (This is a test *foo: (This is *bar: (an element) inside an
> element),[12,25],*bin: (@bar: (term) More text))
>
> HTML would be encoded as *html: (*head: (*title: (This is the top title)
> *link: (@rel: (stylesheet) @href:(my.css)) *body: (*h1: (This is the page
> title) *p:(This is a *b: (test).)))
"Terse" and "simple" are not the same thing.
Note also that
*html: (*head: (*title: (This is the top title) *link: (@rel:
(stylesheet) @href:(my.css)) *body: (*h1: (This is the page
title) *p:(This is a *b: (test).)))
and
*html: (*head: (*title: (This is the top title *link: (@rel:
(stylesheet) @href:(my.css))) *body: (*h1: (This is the page
title) *p:(This is a *b: (test).)))
are very different documents...
[
Date Prev]
| [
Thread Prev]
| [
Thread Next]
| [
Date Next]
--
[
Date Index]
| [
Thread Index]
