>Eclipse: RelaxNG Tools Editor

>A few weeks ago I blogged about a RelaxNG Compact Syntax editor and how I was trying to use XText to generate the editor. Since that time, with the help of the XText folks, I’ve worked around a few of the big hurdles. First thing to note is that there isn’t a one-to-one relationship mapping between EBNF and XText. This can make getting an existing grammar implemented trickier than it needs to be. With a little hand holding of XText, and lots of cursing later, I have a mostly working editor.

Most of the various grammars and patterns validate correctly, expect one.

If there are multiple levels the attributes end tag “}” is being flagged in error. I haven’t worked out yet why this is happening, but every other grammar example I can toss at the editor seems to be validating correctly now. XText in some ways is being pushed to it’s limits with the RelaxNG DSL. It’s being very picky on how the grammar has to be setup. One major limitation in my opinion is not being able to handle the following with out compilation errors:

Pattern “&”
Pattern “+” Pattern

This makes for some ugly work arounds in the XText language to get it to generate the desired syntax and error handling.

With this said, I’m still impressed by the ability of generated Editor, and look forward to future versions of XText. It’s a tool that can be useful, depending on the need.

This entry was posted in eclipse, xml, xtext. Bookmark the permalink.

2 Responses to >Eclipse: RelaxNG Tools Editor

  1. >It's definitely not a limitation of Xtext, but a problem in your grammar. Why don't you use the newsgroup to ask questions? Your issues are user issues not limitations in the framework. It's not nice to blame frameworks only because you don't know how to use them.

  2. David Carver says:

    >Sven:Actually it is a limitation if I have to rewrite parts of the grammar to handle a common issue. I'll use the newsgroup as I do have a couple of issues to work out. Sven you are correct in that I'm still in the learning curve mode, but it is a problem when something documented in a standard like EBNF has to be rewritten in a more complicated methodology to handle the unsupported left-right-left situation of patterns repeating. While I realize XText isn't EBNF, it still stands that there isn't a complete 1 to 1 feature support without jumping through some hoops and reworking pieces of an existing grammer. Java CUP has some of the same issues that we have had to work around with it for parsing XPath 2.0 grammars. Constructive criticisms are how things get improved, which I think I have done with my entries. XText is at 0.7, so I totally expect XText to keep continuing to improve. I still also say that the one issue I did report is still an issue, i.e. bug 282475 from an end users standpoint.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s