While it's true that Glimmerized XML syntax can now handle namespaces, support is not complete yet as pointed out in a comment by Ed Merks, the co-architect of the Eclipse Modeling Framework.
How do you include attributes that have qualified names?
Here is how it is done in XML:
<label bundle:key="contact.firstName" >
<text ajax:id="firstName" />
</label>
Glimmerized syntax now supports that as follows:
label(bundle.key => "contact.firstName") {
text(ajax.id => "firstName")
}
How do you declare XML namespaces?
Using the same mechanism.
Here is an example of an XML declaration of a namespace:
<billing:price xmlns:billing="http://billing.system.biz/schema" units="CAN">47.38</billing:price>
Here is the same example written with Glimmerized syntax:
billing.price xmlns.billing=>"http://billing.system.biz/schema", units=>"CAN" {"47.38"}
Notice how attribute names do not have to be Ruby symbols anymore (e.g. units => "CAN" instead of :units => "CAN".) Ed's suggestion to drop the colon coincided with the need to support prefixes, so the syntax has been enhanced to allow qualified names, which were not possible with symbols.
Stay tuned for more on how to include simple text or mixed text in an element body.
5 comments:
Hey Andy,
this is a nice experiment, but it just looks like a pale copy of Builder:
http://www.xml.com/pub/a/2006/01/04/creating-xml-with-ruby-and-builder.html?page=2
They do support namespaces too:
http://builder.rubyforge.org/
Next question is: how do you set encoding ? How do you add comments ?
More generally, what use do you think people will make of your stuff with a stable API like Builder already out there ? How do you relate this to Eclipse ?
All of this additional stuff is starting to make me like the original XML syntax better.
Also keep in mind that the the prefixes can and will be anything, it's the namespace that the prefix is matched too that is the important item. Once you start adding all the various support that XML has, the solution becomes almost harder to read than the original XML.
Hi antoine,
While some people can barely distinguish Pepsi's taste from Coke, there are others who strongly notice the subtle differences in the carbonation and aftertaste, and prefer one over the other.
Let's just say that while Glimmer XML seems very similar to Builder, my original intention behind it wasn't to copy Builder, yet to provide the easiest Ruby DSL possible for creating XML and XHTML.
Take mixed content for an example:
<p>This text is <em>emphasized</em> for importance.</p>
Here is how you would author it with Builder:
x.p{ |y| y << "This text is "; x.em "emphasized"; y << " for importance." }
Here is how you would author it with Glimmer:
p{ "This text is #em{emphasized} for importance." }
Notice how all the extra characters in the Builder syntax make it more difficult to author mixed content than doing it with actual XML (that is probably the point David was trying to make.) On the other hand, Glimmer's minimalistic syntax solves the problem and makes it easier to author mixed content.
I appreciate Builder's attempt to make authoring XML easier, but I can see some areas that can use improvement, so think of Glimmer XML as simply constructive feedback about them.
Regarding stability, take a look at the Glimmer SVN repository, and you will notice that all of its code was test-driven with unit-tests, so this gives us one level of confidence at least. Of course, there are a number of scenarios and special cases to address. But since we're in the open-source world, if that ever poses a problem, I could always reuse Builder as the engine behind Glimmer's XML syntax. :-)
Besides, nothing prevents us from later contributing Glimmer's XML syntax directly to Builder if needed. So, let's look at Glimmer XML as more of a research to figure out the easiest way to author XML rather than competition with other frameworks.
Andy,
maybe I should rephrase:
why ?
Builder is there and does 99% of what you do. I am sure they must test cases as well. Why investing so much work into something that is already existing ? Instead, how about helping the Builder guys to support 100% of what you want to do ?
This is not a fight about Pepsi vs Coke. You are not building products on a competitive market. Open source is about commoditization.
why ?
Because programming is fun and because I wanted to test Glimmer's engine flexibility for accommodating new DSLs other than the original one built for SWT.
Builder is there and does 99% of what you do. I am sure they must test cases as well. Why investing so much work into something that is already existing ? Instead, how about helping the Builder guys to support 100% of what you want to do ?
The beauty of the Ruby language is that the whole effort barely took any time in comparison to typical software projects. Additionally, Glimmer's flexible engine makes it super easy and quick to build a hierarchical DSL, and the Glimmer XML DSL was an experiment to prove that. Like I said before, once the experiment is over, it is always possible to consolidate any discovered ideas that helped simplify XML authoring into Builder.
This is not a fight about Pepsi vs Coke. You are not building products on a competitive market.
I used the Pepsi vs Coke analogy as a metaphor for products with subtle differences that are missed by some people, yet strongly noticed by others. I am not using the analogy to express that there is competition.
Open source is about commoditization.
Agreed. That was sort of implied when I said this:
"So, let's look at Glimmer XML as more of a research to figure out the easiest way to author XML rather than competition with other frameworks."
Thanks for sharing your opinion Antoine.
Post a Comment