XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML Redux

One last point, after reading through my previous post:

Such a notation doesn't preclude namespaces also using the colon (":") character; as far as I'm aware there should be no instance where a colon ever appears as the end character in XML. I.e., 

(svg:circle:(@r:(10) @fill:(red) @cx:(100) @cy:(120) @myns:foo:(bar)))

works just fine.

I also suspect that you could use implied parentheses when the first term is interpreted, but that may make parsing more complex. That is,

(svg:circle:( @r: 10 @fill: red @cx: 100 @cy: 120 @myns:foo: bar))

is probably more legible, but may be more ambiguous in terms of its interpretation. Will have to think about that one.

Finally, I've been using enclosing parameters simply an an indication that the expression is an implied sequence, but I'm not really sure that's necessary either. This would mean that a normal text block with internal markup but no container could in fact be kept as is:

It was the i:best of times, it was the i:(worst of times). 

would be converted into an XDM model of

("It was the ",<i>best</i>,"of times, it was the ",<i>worst of times</i>,".")

If you had dual wrapped elements that were implied, then you would have to watch white space:

It was the b: i:best of times.

would be interpreted as

("It was the ",<b><i>best</i></b>," of times.")

while

It was the b:i:best of times.

would be

("It was the ",<b:i>best</b:i>," of times.")

Making this explicit would of course resolve the dilemma:

It was the b:(i:(best)) of times.

 
Kurt Cagle
Invited Expert, Forms Working Group, W3C
kurt.cagle@gmail.com
443-837-8725


On Tue, Feb 15, 2011 at 1:01 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:
I like Dave Pawson's use of the <> as formal markup delimiters, but I'd still kind of point to the XQuery XDM and question whether, with a few syntactic shortcuts you couldn't get something that still satisfies the XDM while at the same time giving you a JSON-esque notation. Consider the following:

("This is a test",<foo>This is <bar>an element</bar> inside an element</foo>,12,25,<bin bat="term">More text</bin>)

Rewrite this in XQuery constructor notation:

("This is a test", element foo {('This is ',element bar {'an element'},' inside an element.')},12,25,element bin {(attribute bat {"term"},"More text"}))

Replace element foo with *foo: (), attribute bar with @bar: () :

("This is a test",*foo: ("This is ",*bar: ('an element'),'inside an element'),12,25,*bin: (@bar: "term","More text"))

You could even go a step further by assuming that the constructs *foo: () automatically "escapes out" of text. Additionally sequence items that need to be separated could be placed in a [] structure:

(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).)))

Finally, it may be possible to eliminate the * notation altogether:

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).)))

This doesn't break XML, beyond the document vs. grove issue (which has always been one of the more questionable characteristics of the XML spec), is compact, more or less readable, and can be readily mapped to JSON. For instance, consider a structure of the form:

For instance, a list of strings could be differentiated with []:

colors: (["red","green","blue","yellow"])

JSON would interpret this as:

{colors: ["red","green","blue","yellow"]}

while XML would interpret it as

<colors xsi:type="xs:NMTokens">red green blue yellow</colors>

or, worst case:

<colors>
     <xml:null>red</xml:null>
     <xml:null>green</xml:null>
     <xml:null>blue</xml:null>
     <xml:null>yellow</xml:null>
</colors>

(The case of a list of strings is one where the XDM is superior to the serialization model, since the angle bracket serialization has no notion of the concept of a list). 

This is a declarative description, not a functional one, but that doesn't mean that you couldn't take advantage of XQuery like constructs:

let $title1 := "This is the top title"
let $title2 := "This is the page title"
let $page := html: (head: (title: ({$title1}) link: (@rel: (stylesheet)  @href: (my.css)) body: (h1: ({$title2}) p: (This is a b: (test).)))
return $page

and as white space isn't that much of a concern:

let $page := 
   html: (       
      head: (
           title: ({$title1})
           link: (
                 @rel: (stylesheet)
                 @href: (my.css)
                 )
           )
      body: (
          h1: ({$title2})
          p: (This is a b: (test).)
      )
   )

Note that this is the primary reason why I haven't used the curly brace for this particular notation; it's become too thoroughly established as an escape mechanism for the underlying scripting environment.

Finally, taking Michael Kay's example:

{  authors: [
      {name: "Michael Kay", affiliation: "Saxonica"},
      {name: "Liam Quin", affiliation: "W3C"}
   ]
   abstract:<para { style : "bold" }>Here be some dragons</para>
   content:<section { numbers : [1,1,2] }><para>...</para></section>
}

remap that in the above notation:

(authors: (
    [null: (name: (Michael Kay) affiliation: (Saxonica)), 
     null: (name: (Liam Quin) affiliation: (W3C))] 
    abstract: (para: (@style: (bold) Here be dragons)
    content: (section: (numbers: ([1,1,2]) para: (...))
    )

or, if you use the notation : ( by itself to indicate an "anonyous" class:

(authors: (
    [ : (name: (Michael Kay) affiliation: (Saxonica)), 
      : (name: (Liam Quin) affiliation: (W3C))] 
    abstract: (para:(@style: (bold) Here be dragons)
    content: (section:(numbers: ([1,1,2]) para: (...))
    )

Seems pretty straightforward to me, should be fairly easily parseable, and has the advantage of being trivial to wrap within a string. Additionall, "foo : (bar)" is not exactly a common construct lexically, even without whitespace, and escaping it could simply involve the use of a construct such as `foo: (bar)`, with the "`" character indicating that the string should be interpreted literally.

The exact nature of the notation can be argued, but I think the important point to consider is that while the serialization model of XML is not fully congruent with JSON, XDM is. Which means that any discussion about a MicroXML needs to be looking at XDM, rather than the XML 1.0 serialization model, as the basis for that simplification.

This is something that I think has been missing in all of the discussions thus far. This is not a notational issue, it's a data modeling one. There are simply constructs that cannot be modeled readily in JSON that are easily rendered in XML angle bracket notation (ABN) and vice versa, because ABN has no mechanism for defining arrays that doesn't rely either upon a convention (white space NMTokens) while JSON notation for handling semi-repeating XML structures (such as <a>1</a><a>2</a><b>3</b><a>4</a>) can get hideously complex fast. Yet an XDM notation could represent both cases trivially.

Kurt Cagle
Invited Expert, Forms Working Group, W3C
443-837-8725



On Tue, Feb 15, 2011 at 10:49 AM, Michael Kay <mike@saxonica.com> wrote:

But then looking at Mikes
{  authors: [
      {name: "Michael Kay", affiliation: "Saxonica"},
      {name: "Liam Quin", affiliation: "W3C"}
   ]
   abstract:<para { style : "bold" }>Here be some dragons</para>
   content:<section { numbers : [1,1,2] }><para>...</para></section>
}
I'm not sure if content: is markup? I can see authors as a list..
Is content: wrapping<section/>


No. Just as

affiliation : "Saxonica"

is a name-value pair (within a map) where the name is affiliation and the value is a string, so

content: <section><para>...</para></section>

is a name-value pair (within a map) where the name is content and the value is a (textual) element.

This is what I mean about composability between structured data and marked-up text, without being forced to represent the structured data using syntax that was designed for textual markup. (Not dissimilar from putting XML in a column of an RDB, except that (a) the structured data part is more powerful than rows-and-columns, and (b) you can have structured data inside the text content as well as vice versa.)

Michael Kay



_______________________________________________________________________

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





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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS