The lack or real application and distincly "boiler plate" writing, like including a "conclusion" section that states the obvious sure make this look like someone just publishing their school papers for masters or phd work, possibly trying to doctor a resume up or other ....
I do find the articles amusing though, so I for one won't complain if more get published, lol.
The responses to this article have proven one thing to me: a lot of people rate their impression of the subject matter rather than the quality of the article.
I'm not big on the idea of GRML so I doubt I'll ever use it. That doesn't mean the article is garbage though. I think some of the code presented was interesting and could come in handy. The article is reasonably well written and fairly easy to understand.
So, although GRML isn't my cup of tea, I'll give the article a 4.
I have my own design for a round, flat artifact which is very distinct from the wheel, but has more functionality. Unfortunately, I can't convince anyone that my invention is better than the billions of wheels aready in use because everyone already uses it and have no reason to replace it even though my invention is clearly superior, as described on my website.
Bit shift to the left, bit shift to the right.
Push stack, pop stack, byte, byte byte!
On highways, it is very dangerous to drive with wheels make out of rubber, because they can burst. This poses a great security risk. My invention is specifically made out of solid steel, a material impervious to bursting because it doesn't have the functionality of air cussions. The lack of air is not a lack of functionality, but is actually a feature which makes my invention better because it is safer.
Bit shift to the left, bit shift to the right.
Push stack, pop stack, byte, byte byte!
Owww... shi...
I was planning to build my triangular-shaped wheel out of concrete... Now it will look like a poor copy of your magnificient device...
I'm so sorry I think that I will go and hang myself (by the way I've got another new device : it's a rubber cord for hanging, It will be a great archievement to safety for suicide. I already have sent a sample to the health-care system and I'm waiting for their remarks )
(okay, the last one was not a new joke but hey, I'm only a coder I'm not supposed to have ideas)
Okay, as many others, I'll ask ONE question : what is the purpose of GRML ?
To me it's look like a copycat of XML, with a rather strange model (sorry). Looking at your website, I've found the followind grml snippet :
<grml>
<a control=result_13 type=Item>Jul 28</>
<a control=result_13 type=Item>Sr. Java Software Engineer</>
<a control=result_13 type=Item>US-CA-La Jolla</>
<a control=result_13 type=Item>Company A</>
<a control=result_13 type=Item>Java LA</>
<a control=result_13 type=Item>Today</>
and you say that assigned to a listview it should build a nice listview with an header (containing the last line of data). My question is: how ? that's pretty bad designed, with no hierarchy of data or anything.
Please consider the almost equivalent XML Snippet (not the best I can do, but I don't want a pulizer for this post):
<Data>
<Header><Col>Date Posted</Col><Col>......</Col></Header>
<Item><Col>Jul 28</Col><Col>Java ....</Col></Item>
</Data>
A nice XSLT on that snippet and you'll get a real HTML (or XAML if you want GUI) that display the data. If you want to parse and display by yourself, you'll have SAX or any other xml-parser to simplify the process...
Read the article Introducing GRML. It explains the purpose of GRML and why it exists.
The XML above is nested, which is something that GRML specifically avoids. Plus, there are multiple items per line. That is something else GRML was designed to avoid. In my opinion, it is not very easy on the eyes when looking through a file or web page.
I have considered hierarchical data, but sometimes you just have to decide to do one thing and not try to do too much. There are not too many examples of hierachical web content, outside of navigation.
This message board is an example of hierarchical data, but most message boards use a flat scheme. So, it was a design decision not to focus on it.
If hierarchical data is in demand, there are ways for GRML to support it. However, you are the first person to mention it, after 2 years!.
The markup language definitely needs to be streamlined. That is a priority upgrade before releasing the next GRML web browser.
* mixing data AND view in the same content-holder (file)
* being touchy about the way the data is displayed in the SOURCE file (you say that there should not be 2 items on the same line)
* build a flat representation of data
Am I Right ? If yes, GRML is clearly not for me...
I, in fact, have on question on the code sample I have seen on your website : how do a parser understand the code ? It lacks a clear separator between items (or is it the blank line ?), it don't have a clue about which line IS the header and which are the dataitem (okay I understand that the control tag seems the way to do it but it's not really clear when first reading your sample column_13 is not what I found explicit...). If that's so, you should make some effort in building a SGML-derived "language" with attributes that are more easy to understand at first glance.
If I really have a advice for your "next release" of GRML : make it a subset of XML (or mabye simply an XML with a good DTD), and add a small but useful nesting support, I strongly suggest at least one level to divide heading and data and/or heading and form.
I suggest reading Introducing GRML with regard to the data and view. Take note of the Quick Reference. It provides a brief summary of the web formats and how the terms data, form, and view are used in GRML.
You are right about being touchy about the way data appears in the source file. I spend a lot of time preparing and using hard-to-read data files, so any effort to make them more readable is time well spent, in my opinion.
Correct about the flat representation of data. It is used by so many data sources (databases, spreadsheets, assorted analysis tools) and has proven itself over the years.
Right again about the parser handling the example GRML. It is needlessly complicated. There are going to be some real improvements to drop the size and number of required elements of each tag. It makes the parser code easier to maintain and minimizes file sizes without losing any features or potential upgrades.
I have been considering the best way to add hierarchical support and distinguish form and data elements. However, there is no way GRML is going to require or use nesting to specify item attributes.
To me, nesting says object-oriented. That is not the direction GRML is heading.
Having said that, these are not easy issues to resolve, but know that they will be a part of the upcoming improvements.
GRML is not for everyone. It may not be for most people. Fortunately, it does not depend on any of those things. GRML is designed to just work, without a lot of effort.
Get your data. Add some GRML tags. Use it the way you want. This does not appeal to everyone. That's okay.
That was my point : building something easy to understand, small and simple to parse.
I'll add a closing tag to each of the data through, making it a well-formed SGML syntax like :
<column>
<date>Date Posted</date>
...
</column>
or you could set the value in an attribute like (and closing the tag with a end marker (/) for "well-formedness") :
<column>
<date value="Date Posted" />
...
</column>
That will make the file a little bit bigger but will allow for easier parsing using regular expressions or hand-made parser.
be easy to read or browse when viewing the source,
be easy to parse using C++/regular expressions, and
have the smallest file size possible.
I am considering using an end tag for each item. The only problem is someone might think they can spread content over multiple lines. The next thing you know, they are trying to create a HTML style web page using GRML. Then, they will want bold tags, and tables, and it is just HTML all over again.
Parsing, with or without the end tag seems to be the same (I tried both C++ and Perl just to make sure).
Using the <col value=... /> approach has the advantage of no end tag. When parsing, you have to worry about people doing value="value="hello"" or something similar.
I am going to test out all these approaches and figure out which one works the best.
I still don't think about using GRML but at least it won't hurt my feelings so much
The last thing I'll say about GRML is that you should find a way to "end-tag" your tags (or at least to find a way for not using carriage returns as the end of tag), that have 2 benefits :
* Allow for multilines (even if you don't find it interesting, it really is, I will never forget a 2500 chars line I've seen in a HTML file on an old project). New lines in a xml file,for example, are useful only for "source-code" reading and are mostly ignored by the parser
* make UNIX/Windows/Mac file transfer more easy : you won't have to check the whole CrLf/Cr/Lf matter if you have a close tag : the tag starts with a <xx> and end with a <xx> and that's all ! In a HTTP world it will help (a little) the ease of tranfer.
Hopefully, you'll find a way about that all (and I'v not said that XML is mostly the way.... oooops, holy sh... I've said it !!;P).
What is the purpose or GRML? I have not been able to understand what the difference between it and the existing languages currently employed. I'd appreciate some clarification on this matter.
Also, if you want to create a new language, the best idea would be to make a recommendation to the W3C[^]. Try posting on the forums. Beware on their forums though, there are a lot of ultra-smart people there.
After reading your previous articles, viewing your website, etc., I've come to the conclusion that you aren't trying to solve a problem with any of your technology. Successful technology is made when a problem is discovered, and the solution is appropriately crafted, usually by modifying an existing solution.
You are doing the exact opposite. You have spent a lot of effort creating a solution. Now, you're trying to shoehorn your solution into a series of problems that don't exist.
According to your website, you're trying to reduce costs. However, you're doing it in such a way that a)people's existing skillsets cannot be used, b)relies on an unproven and nonstandard technology, c)requires the use of your client app rather than a standard browser [thereby increasing support costs], d)generates markup that is generally larger than the same page in HTML would be, e)has no real users (on your site forum, the largest forum had 10 posts) and f)is incompatible with the vast majority of software for people with disabilities, such as screen readers.
Not even your own forum is done in GRML, so how can we trust a technology that you don't even use for yourself?
It's obvious that you have some programming skill for writing parsers and the like, but your ego that is driving you to push out these vanity articles to push your self-named "standard" is going to hold you back. Grow up, find your problems first, then solve them.
First, let me say thanks for the input. It is always helpful to know what you think and your impressions.
It is unfortunate, but my website is still being developed. There is a lot of work yet to do in conveying the right message regarding GRML. If you are monitoring its progress, expect to see continual changes as work is completed.
The only thing to say about GRML right now is that there is so much left to do before everything is explained in the proper detail.
One step at a time. I have to remind myself, "Rome wasn't built in a day."