1. RE: Alternative for XML
Tommy Carlier wrote:
> I've created a markup language as an alternative for XML. I call it SMEL
>
> (Some Modest Extensible Language). It behaves a bit like XML, but it's
> more
> compact, and has some advanced features that XML doesn't have.
I don't know the finer details of XML ... but have you looked at YAML?
http://yaml.org (seems to down at the moment)
Regards,
Ray Smith
http://rays-web.com
2. RE: Alternative for XML
Ray Smith wrote:
> Tommy Carlier wrote:
> > I've created a markup language as an alternative for XML. I call it SMEL
> >
> >
> > (Some Modest Extensible Language). It behaves a bit like XML, but it's
> > more
> > compact, and has some advanced features that XML doesn't have.
>
> I don't know the finer details of XML ... but have you looked at YAML?
>
> http://yaml.org (seems to down at the moment)
Yes, I've looked at YAML, and it's a fine language. But it's not that
flexible: it's focused on data-structuring, and not really suitable for
document-structuring. And it's line-based, with indentation to define
the hierarchy. In YAML, you can't create a complicated structure in only
1 line.
If you want to create a compact data-structure, in SMEL you can use a
Euphoria-sequence-looking structure:
{{"Just some data", "in tabular form"},{"with 2 rows", "and 2 columns"}}
3. RE: Alternative for XML
Derek Parnell wrote:
> ----- Original Message -----
> From: "Tommy Carlier" <tommy.carlier at pandora.be>
> To: "EUforum" <EUforum at topica.com>
> Subject: Alternative for XML
> > I've created a markup language as an alternative for XML. I call it SMEL
> >
> > (Some Modest Extensible Language). It behaves a bit like XML, but it's
> > more
> > compact, and has some advanced features that XML doesn't have. To my
> > opinion, it's also more human-readable, especially for programmers.
> >
> > I'm also making a Euphoria-library for reading and writing
> > SMEL-documents.
> > Is this a good idea? Would Euphoria-programmers use SMEL, or would they
> > prefer using XML?
> > Example: the XML-fragment:
> >
> > <?xml version="1.0"?>
> > <data>
> > <element attribute="value" attribute2="value2">Some data</element>
> > <empty/>
> > </data>
> >
> > translated into SMEL:
> >
> > <smel version="1.0">
> > data
> > {
> > element(attribute="value",attribute2="value2"){"Some data"}
> > empty;
> > }
> Interesting. I've been playing with something very similar for use with
> win32lib. Your syntax is more inclusive than I need but it might be
> worth me standardizing on SMEL.
> Also, you might also like to consider non-text attribute values, and
> removing the '=' symbol. For example ...
> <smel version{1.0}>
> data
> {
> element(attribute{value},attribute2{value2}){"Some data"}
> empty;
> }
> For win32lib, I could do something like ...
> <smel version{1.0}>
> form{
> control{type{Window},
> caption{Hello, World!},
> left{12},
> top{10},
> width{300},
> height{300},
> flags{WS_VISIBLE, WS_DLGFRAME}
> },
> control{type{EditText},
> name{UserId},
> left{5}, top{5}
> width(units{char}){20}
> }
> control{type{Button},
> caption{Close},
> flags{autoclose},
> left(from{UserId}){2},
> bottom{5}
> }
> }
> ...hmmmm... I'll think about it some more.
> --
> Derek
Thanks for showing the interest in SMEL. In standard SMEL, as it exists
now, the above Win32Lib-definitions would look like this:
<smel version='1.0'>
form
{
control(type='Window',
caption='Hello, World!',
left='12',
top='10',
width='300',
height='300',
flags='WS_VISIBLE,WS_DLGFRAME')
{
/* the child-controls can be defined in the body of the
parent-control */
control(type='EditText',
name='UserId',
left='5', top='5'
width='20ch'); /* 20ch = 20 chars: unit as part of the
value */
control(type='Button',
caption='Close',
flags='autoclose',
left='UserId+2',
bottom='5');
}
}
This is just an example. You can build much more powerful constructions
than that with SMEL. I'll try and post a version of the SMEL-library as
soon as possible.
I'm also working on SMEL-applications: specifications of SMEL-document
formats like SMELS (SMEL Schema) for defining new SMEL-formats, and
SMELT (SMEL Transformations) for transforming SMEL-formats to other
SMEL-formats or to other text-formats (like XML or HTML).
More suggestions are welcome.
4. RE: Alternative for XML
C. K. Lester wrote:
>
>
> > This is just an example. You can build much more powerful constructions
> > than that with SMEL. I'll try and post a version of the SMEL-library as
> > soon as possible.
> > I'm also working on SMEL-applications: specifications of SMEL-document
> > formats like SMELS (SMEL Schema) for defining new SMEL-formats, and
> > SMELT (SMEL Transformations) for transforming SMEL-formats to other
> > SMEL-formats or to other text-formats (like XML or HTML).
> >
> > More suggestions are welcome.
>
> Change the name. SMEL? Like, stink? :)
>
To find out how I got to that name, look at Google Groups:
http://groups.google.be/groups?threadm=e33f09ac.0307160246.6b6d15a6%40posting.google.com
posting 20 & 21.
5. RE: Alternative for XML
Derek Parnell wrote:
> I realize that things can be seen in multiple ways, and I can see that
> you are expressing the hierarchical nature of the form here, but I can
> see that there will be discussions about 'is such-and-such an "element"
> or an "attribute"?' Maybe you need to give us a guide as to what the
> differences between elements and attributes are?
>
> Also, I really think that numeric values can be expressed as such and
> not as strings. Also, as attributes are delimited by a comma, only
> strings that contain commas need to have quotes. Another issue is how
> can we express nested data in attributes? I suggest that instead of
> quotes, we use the braces characters.
>
> <smel version='1.0'>
> form
> {
> /* First we encode the attributes of 'form' */
> control(type=Window,
> caption={Hello, World!},
> at={12,10},
> size={300,300},
> flags={WS_VISIBLE,WS_DLGFRAME})
> /* And now the elements in 'form' */
> {
> /* the child-controls can be defined in the body of the parent-control
> */
> control(type=EditText,
> name=UserId,
> left=5, top=5,
> width=20ch); /* 20ch = 20 chars: unit as part of the value */
> control(type=Button,
> caption=Close,
> flags=autoclose,
> left=UserId+2,
> bottom=5);
> }
> }
> --
> Derek
The current version of SMEL is inspired on XML and behaves a lot like
XML. That means: "attribute values are always string and need quotes."
In your code I can see sequences as attribute values. This is an
extremely nice feature. However, to implement this I'll have to totally
redesign SMEL, and rewrite the parser. But, because these features will
make SMEL much more powerful, and because SMEL is still just a
work-in-progress, I'll just do that: I'll first create a specification
for SMEL, I'll throw it on the Internet and wait for reactions and new
ideas, and when the specification is kind of solid, I'll begin to make a
new parser.
The difference between elements and attributes?
Elements can be compared to objects, and attributes are the properties
of an object. Or, when you know object-oriented programming, elements
are classes and attributes are class members/properties.
Example: apple(color="green", taste="sweet");
Example: form(name="Form1", width="300", height="200", text="Form 1");
You could also use child-elements instead of attributes:
apple { color { "green" } taste { "sweet" } }
form { name { "Form1" }, width { "300" }, height { "200" }, text { "Form
1" } }
But I think this is a bad design.
Nested data in attributes?
In the current version of SMEL, this isn't possible. This is just
because SMEL is inspired by XML, and XML also doesn't allow nested data
in attributes.
I'm starting a new website (tommy online), with Euphoria-stuff and a
SMEL-section. Because I've just started, very little pages are online
and a lot of links don't work yet. You can find 'tommy online' at
http://users.pandora.be/tommycarlier
