I'm looking for a name for a my new XML-like language.

T

Tommy Carlier

I've created a data structuring format (you can't really call it a
markup language), that behaves like XML, but that's much more
flexible. You can have elements without names, attributes without
names, you don't need something like CDATA or entities, and there's no
such thing as DTD.

Now I'm looking for an interesting name for it. I've thought of using
a name like *ML (replace the * by any letter), but all the letters
were already taken.

Now I think I might not use an acronym: there are already too much of
them. So I'm looking for a symbolic name, perhaps an animal name.

The format is a lot smaller than XML, less verbose but still
human-readable. It's optimized for small files, fast and small parsers
and intelligent usage.

Can anyone help me?
 
H

hilz

WTFML?????????????
:)
just kidding....
just came to my mind and i though i must say it!
hehe
:)
 
P

Peter Flynn

Tommy said:
I've created a data structuring format (you can't really call it a
markup language), that behaves like XML, but that's much more
flexible. You can have elements without names, attributes without
names, you don't need something like CDATA or entities, and there's no
such thing as DTD.

What use is it?

///Peter
 
T

Tommy Carlier

Kurt Svensson said:
Tommy Carlier wanted a name on his special brand of XML

Call it: TCML (Tommy Carlier Mysterious Language)

Regards
Kurt Svensson
www.inobiz.com

It's not really a special brand of XML, it's an alternative for XML.

XML looks like:

<?xml version="1.0"?>
<html>
<head><title>Title of the document</title></head>
<body bgcolor="#FFFFFF">
<h1>A header</h1>
<p>
A paragraph with a horizontal line: <hr/>
</p>
</body>
</html>

In my language, the previous document would look like:

<xml version="1.0">
html
{
head { title { "Title of the document" } }
body ( bgcolor="#FFFFFF" )
{
h1 { "A header" }
p
{
"A paragraph with a horizontal line:" hr;
}
}
}

If you remove all unnecessary spaces, you get:

<?xml version="1.0"?><html><head><title>Title of the
document</title></head><body bgcolor="#FFFFFF"><h1>A header</h1><p>A
paragraph with a horizontal line:<hr/></p></body></html>

versus:

<xml version="1.0">html{head{title{"Title of the
document"}}body(bgcolor="#FFFFFF"){h1{"A header"}p{"A paragraph with a
horizontal line:"hr;}}}
 
B

Bob Foster

Doesn't seem that much more concise or easier to read.

Bob
P.S. That <xml version="1.0"> doesn't belong there.
P.P.S. To heck with trivial examples, let's see how the schema for XML
Schema looks in this language.
 
T

Tommy Carlier

What's easier to read:
<title>A title</title>
or
title { "A title" }

I think it's a little easier to read the second. And it's smaller, so
faster to transport and faster to parse. The BNF-notation of the
format is also a lot smaller and less complex than that of XML, so a
parser should also be less complex.

The language also has other features like elements with no name,
attributes without a name or a value, ...

It's much cleaner to work with lists and tables:
in XML/HTML a list would look like:
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>

In my format, you can write a list like:
ul
{
li { "Item 1" }
li { "Item 2" }
li { "Item 3" }
}

Because the children of a list are always LI-elements, you can leave
the name LI away, and because the elements only have 1 text-element as
a child, you can leave the { and } away too, so the code would look
like:
ul
{
"Item 1"
"Item 2"
"Item 3"
}

Now remove all the unnecessary spaces, and you get:
<ul><li>Item 1</li><li>Item 2</li><li>Item 3</li></ul>
versus
ul{"Item 1""Item 2""Item 2"}

Think of what it can do to tables if you know that the children of a
TABLE-element are always rows (TR) and the children of rows are always
cells (TD).

Now I'm still looking for a name :)
 
C

Colin Mackenzie

is it still easier to read if you have a nesting of say 30 elements deep
sounds like a lot of

}}}}}}}}}}}}}}}}}

to me
which } closed the opening element?

Colin
 
S

Steven Dilley

Tommy Carlier said:
What's easier to read:
<title>A title</title>
or
title { "A title" }

I think it's a little easier to read the second. And it's smaller, so
faster to transport and faster to parse.

Comm links usually have some kind of compression algorithm.
Zip both versions and see which is smaller, and by how much.
Compression squeezes repetition & xml tags tend to be repetitive.
 
G

GIMME

How about SMEL ?

(S)uper (M)agic (E)xcellent (L)anguage pronounced SMELL

Then call your transforms SMELTs .

It has a clever ring to it especially for when things go wrong ...


If you prounce XML as egg-smell then you'd have ...



We used to use XML but now we use SMEL.

It things used to work great, they used to work swell,

The day it failed I couldn't describe how I felt.

I had never SMELT a SMELT like that SMELT SMELT
 
T

Tommy Carlier

(e-mail address removed) (GIMME) wrote in
How about SMEL ?
(S)uper (M)agic (E)xcellent (L)anguage pronounced SMELL
Then call your transforms SMELTs .

It has a clever ring to it especially for when things go wrong ...
If you pronounce XML as egg-smell then you'd have ...

We used to use XML but now we use SMEL.
If things used to work great, they used to work swell,
The day it failed I couldn't describe how I felt.
I had never SMELT a SMELT like that SMELT SMELT

Nice one, I'll consider using it :D
Perhaps I'll modify it a little, since Super Magic Excellent Language
sounds a little like "I'm the best programmer in the world and there's no
better language than mine and all the others suck."

What about (S)ome (M)odest (E)xtensible (L)anguage?
 
T

Tommy Carlier

Comm links usually have some kind of compression algorithm.
Zip both versions and see which is smaller, and by how much.
Compression squeezes repetition & xml tags tend to be repetitive.

OK, if compressed the difference in size between XML and ?ML won't be that
big, but to parse it you have to decompress it first, and the less
characters to parse, the faster the parser will work.
 
K

Keith M. Corbett

Now remove all the unnecessary spaces, and you get:
<ul><li>Item 1</li><li>Item 2</li><li>Item 3</li></ul>
versus
ul{"Item 1""Item 2""Item 2"}

Now you're one parenthesis level away from re-inventing LISP syntax for
list-structured data:

(ul ("Item 1" "Item 2" "Item 3"))

You can freely combine program code and data!. Tons o' fun.

LISP has been around for 40+ years. CommonLISP is an ISO standard, so you've
got that working for you.

/kmc
 
T

Tommy Carlier

Keith M. Corbett said:
Now you're one parenthesis level away from re-inventing LISP syntax
for list-structured data:
(ul ("Item 1" "Item 2" "Item 3"))
You can freely combine program code and data!. Tons o' fun.
LISP has been around for 40+ years. CommonLISP is an ISO standard, so
you've got that working for you.
/kmc

I used the notation ELEMENT(ATTRIBUTES){CHILDREN} because I'm used to
programming in languages like C, C++ and C#, and that notation is used
quite a lot there: if(...){...}, while(...){...}, void(...){...},...

Yes, I was inspired by program code notation, only it wasn't LISP. Although
I think the LISP-notation would also be a good alternative.

So I thought it would be easier for programmers to read this code than to
read XML. I've already got a working parser in the rather unknown
programming language Euphoria (http://www.RapidEuphoria.com), but I'm
thinking of creating parsers in other languages like C#, C, Java,... If
anyone wants to help me create parsers and other tools, feel free to send
me an e-mail, or post a response to this thread.
 
B

Bruno Desthuilliers

Tommy Carlier wrote:

(snip)
It's much cleaner to work with lists and tables:
in XML/HTML a list would look like:
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>

In my format, you can write a list like:
ul
{
li { "Item 1" }
li { "Item 2" }
li { "Item 3" }
}

Because the children of a list are always LI-elements,

Ho, really ?

Funny, I use nested lists, and that works quite fine in HTML :
<ul>
<li>item1</li>
<li>item2></li>
<ul>
<li>item2-1</li>
<li>item2-2</li>
</ul>
you can leave
the name LI away, and because the elements only have 1 text-element as
a child, you can leave the { and } away too, so the code would look
like:
ul
{
"Item 1"
"Item 2"
"Item 3"
}

Now what would my nested lists look like ? This ?

ul
{
"item1"
"item2"
ul
{
"item2-1"
"item2-2"
}
}


Bruno
 
S

Steven Dilley

Keith M. Corbett said:
Now you're one parenthesis level away from re-inventing LISP syntax for
list-structured data:

(ul ("Item 1" "Item 2" "Item 3"))

Actually, he is zero braces and a few quotes away from CSS.
ul {color:blue; }
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top