The Artima Developer Community
Sponsored Link

Weblogs Forum
Presenting a Simpler Alternative to XML: PicoML

25 replies on 2 pages. Most recent reply: Nov 20, 2005 10:42 AM by Christopher Diggins

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 25 replies on 2 pages [ « | 1 2 ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 3, 2005 12:24 PM
Reply to this message Reply
Advertisement
> > I have devised a simple mark-up scheme for my own
> purposes
>
> Is it for your human readable abstract trees ? (Your
> previous ASTXML post)

This is the main goal. I don't really want to work directly with XML, it is too bulky, so I am looking at formats which can be trivially transformed to and from XML.

> > What do you think?
>
> Lack of namespace support, maybe ;)

I wonder how crucial namespace support truly is. Can a markup language still be useful without it?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

I always use NextStep classic PLists Posted: Nov 3, 2005 1:39 PM
Reply to this message Reply
I have parsers for these in various languages, they take very little code to write and they map directly to collection classes which means you don't need to make up a new DOM.

Dictionary: { key = value; key2 = value2; }
Array: ( item1, item2, item3, )
Element: "C style string literal" | single-token

That's it. Items can nest any way you like, you can use an array or dictionary for a key or value.


{ cd =
{
title = "Maggie May";
artist = "Rod Stewart";
country = UK;
company = Pickwick;
price = 8.50;
year = 1990;
}
}


This format is over ten years old and has wide support. I use it as serialization protocol and use language collection libraries to represent the items, so in Java you get Maps, Lists and Strings, in ObjectiveC its NSDictionary, NSArray, and NSString, in Smalltalk it is Dictionary, Array, String, etc.

Aristotle Pagaltzis

Posts: 1
Nickname: apag
Registered: Nov, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 3, 2005 4:47 PM
Reply to this message Reply
Don’t forget to do something about encodings if you’re inventing your own document markup language.

Don’t invent your own serialisation markup language, use JSON.

Derek Parnell

Posts: 22
Nickname: derekp
Registered: Feb, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 3, 2005 8:17 PM
Reply to this message Reply
> > One of my favourites goes a bit like this (from memory)
>
> The more I look at your markup the more I like it! It is
> essentially an s-expression with labels, which
> significantly enhances plain old s-expressions. If I was
> to modify the spec for my own purposes (giving you credit
> of course) I would make the following changes:

Knock yourself out! I don't care. It's not like I patented anything so I don't need acknowlegement.

> First I would strip the meta_content. I don't see any
> sufficiently compelling reason to have separate meta tags
> versus ordinary tags.

I had them 'cos I wanted a specific place to record stuff about the data in a standized form.

>Next I would remove the special
> requirements for id characters. This would increase the
> speed of the parser, and have an interesting side-effect:
> labels can be used as raw-data.

Yeah, that's probably a hang up from compiler-writing habits.

>Next I would remove the
> string parsing rules (which incidentally you left out of
> the BNF).

Tough ;-)

>Finally I leave out the mismatched non-escaping
> paranthesis rule. It may be convenient for a human, but it
> adds more complexity to the parser.

My idea was oriented for human writing and reading rather than machine.

And in that light, the other trick I had was to make writing and reading tabular data easier.

(session: (user: n00b) (when: 2005 11 03)
(scores# kills, heads, hits, spawns, duration:
( (5) (2) (12) (2) (5:03) )
( (1) (0) (2) (1) (3:12) )
( (0) (0) (0) (1) (0:05) )
( (7) (6) (15) (4) (9:56) )
)
)

This is just a short hand for ...

(session: (user: n00b) (when: 2005 11 03)
(score: (kills:5) (heads:2) (hits:12) (spawns:2) (duration: 5:30))
(score: (kills:1) (heads:0) (hits:2) (spawns:1) (duration: 3:12))
(score: (kills:0) (heads:0) (hits:0) (spawns:1) (duration: 0:05))
(score: (kills:7) (heads:6) (hits:15) (spawns:4) (duration: 9:56))
)


> What do you think?

Use want ever you need.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 3, 2005 10:13 PM
Reply to this message Reply
> Knock yourself out! I don't care. It's not like I patented
> anything so I don't need acknowlegement.

Well I acknowledged you anyway :-)

Check out the new markup language along with a working parser at:

http://www.artima.com/weblogs/viewpost.jsp?thread=135216

Concerning the tabular data, I think that can be handled effectively as follows using unlabelled nodes:


(session:
(user: n00b)
(when: 2005 11 03)
(table:
(head(:scores#)(:kills)(:heads)(:hits)(:spawns)(:duration)
(row:(:5)(:2)(:12)(:2)(:(5':03))
(row:(:1)(:0)(:2)(:1)(:3':12))
(row:(:0)(:0)(:0)(:1)(:0':05))
(row:(:7)(:6)(:15)(:4)(:9':56))
)
)

Sean Conner

Posts: 19
Nickname: spc476
Registered: Aug, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 3, 2005 10:58 PM
Reply to this message Reply
I said: “But in your simpler method, is there a preferred order for the ‘attributes’?”

You replied: “I don't understand the question.”

Fair enough.

An example like HTML: You have the simple link:

<A HREF="link" TITLE="blah">link text</A>

The problem I see is that in XML, attributes of a tag don't follow any specific order. I suppose the following could very well be valid (to borrow your syntax):


(a: (href:link) (title:blah) link text)
(a: (title:blah) link text (href:link))
(a: link text (href:link) (title:blah))


But what about something like:

<P LANG="en-US">Hello <A HREF="link" TITLE="blah"><EM>there</EM></A></P>

Would the following be equivilent?

1. (p: (lang:en-US) Hello (a: (href:link) (title:blah) (em:there)))

2. (p: Hello (lang:en-US) (a: (em:there) (title:blah) (href:link)))

3. (p: (lang:en-US) Hello (a: (title:blah) (em:there) (href:link)))

Three different tree structures and to me, they have subtle differences in meaning.

Attributes (at least, how I understand them, in HTML and XML) modify or extend the meaning of the node they belong to, they are not children of the node.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 4, 2005 9:42 AM
Reply to this message Reply
> Would the following be equivilent?
[snip]

Like XML the answer is, no they are not equivalent, but your processor can treat them equivalently. Just as in XML, order is important sometimes. It really depends on the consumer of the data.

> Attributes (at least, how I understand them, in HTML and
> XML) modify or extend the meaning of the node they belong
> to, they are not children of the node.

That is definitely the intention, but they are not used for that purpose in practice. Furthermore, I argue that XML is intended to convey structure, not meaning, with the data.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 6, 2005 5:12 AM
Reply to this message Reply
Two features of XML that I appreciate are the declaration of the encoding on the first line and the ability to reference characters which are not in that encoding.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 20, 2005 5:54 AM
Reply to this message Reply
> Like XML the answer is, no they are not equivalent, but
> your processor can treat them equivalently.
That's incorrect.
Elements order is relevant and must be treated that way:
<foo/><bar/> !== <bar/><foo/> in all parsers.

There is no attribute order:
<foo a1="" a2=""/> === <foo a2="" a1=""/>
A parser may return the attributes in any order, but usually
will return them in the order they appear.

Therefore, applications must not rely on the fact that the parser returned a1 before a2.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 20, 2005 6:00 AM
Reply to this message Reply
> Like XML the answer is, no they are not equivalent, but
> your processor can treat them equivalently.
Regarding the fact that there is no attribute order in XML:

I think this a very useful feature in practice (XUL):
<button height="100" width="50"/> should be idential to <button width="50" height="100"/>

Likewise, document order is important for elements in many cases:
<vbox>
<label value="foo"/>
<label value="bar"/>
</vbox>

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Presenting a Simpler Alternative to XML: PicoML Posted: Nov 20, 2005 10:42 AM
Reply to this message Reply
> > Like XML the answer is, no they are not equivalent, but
> > your processor can treat them equivalently.
>
> That's incorrect.
> Elements order is relevant and must be treated that way:

You are right from a parser viewpoint. What I am trying to say is that you can create a DTD or Schema which is functionally equivalent. The final interepretation of an XML element may or may not decide that element order is important. In other words, the parser has to care about element order but the data consumer can ignore it.

Flat View: This topic has 25 replies on 2 pages [ « | 1  2 ]
Topic: Generics: Unbounded wildcard puzzle Previous Topic   Next Topic Topic: OsXml - An XML Format for Publishing Open-Source Code


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us