Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Workaround semantic predicates(Workaround semantic predicates)
Workaround semantic predicates [message #1851634] Mon, 11 April 2022 14:04 Go to next message
Antonio Garmendia is currently offline Antonio GarmendiaFriend
Messages: 93
Registered: May 2014
Member
Hi all,

I am currently working on mapping the concepts of JSON Schema (https://json-schema.org/) to Ecore+OCL, and then, generating an Xtext grammar that has json as concrete syntax.

We have a problem with the specifications of PatternProperties [3]. According to the Pattern Properties specifications, when a key matches a given regular expression [4], its value has to conform to a given schema.

In the excerpt of the grammar shown below, when a key matches the regex "a|b", the value has to be parsed as (Some other schema 1), and when a key matches "c|d" the value has to be parsed as (Some other schema 2).

Properties returns Properties:
{Properties}
'{' ( property+=PatternProperties ( ',' property += PatternProperties)* )? '}';

PatternProperties returns PatternProperties:
=>PatternProperties1 | =>PatternProperties2;

// key has to match the regex "a|b"
PatternProperties1 returns PatternProperties1:
{PatternProperties1} key = EString ':' value= ( Some other schema 1) ;

// key has to match the regex "c|d"
PatternProperties2 returns PatternProperties2:
{PatternProperties2} key = EString ':' value= ( Some other schema 2) ;

This case could be solved with semantic predicates, where the condition would be the key matching with the given regular expression. But as far as we know, Xtext does not support the semantic predicate [1].

We have been trying different workarounds, like [2] without success.

Is there any work around in Xtext that solves our problem?

Thank you in advance.

Best regards
[1] https://www.eclipse.org/forums/index.php/t/202846/
[2] https://dslmeinte.wordpress.com/2010/12/08/getting-alternative-cross-references-to-work-with-existing-epackages/
[3]https://json-schema.org/understanding-json-schema/reference/object.html#pattern-properties
[4]https://json-schema.org/understanding-json-schema/reference/regular_expressions.html#regular-expressions

Re: Workaround semantic predicates [message #1851702 is a reply to message #1851634] Tue, 12 April 2022 19:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7518
Registered: July 2009
Senior Member
Hi

Semantics predicates are one way to go, but not my favoured approach at all, since the basic premise is that you start from a bad grammar and force its ambiguities in a 'good' direction. This can work, but in my experience it can easily leading to silently excluding an alternative that the user would prefer. Attempting to resolve the problem in the parser is hard if not impossible because you have to make a decision while the source text is only half parsed. You can of course throw yourself on the mercies of backtracking and keep your fingers crossed.

Consequently I prefer a different approach. Preferably you change the language to eliminate the ambiguities, but in the real world external / legacy compatibility forces something else, for which the solution is what I call a superset grammar whereby each ambiguity is accommodated bv a unified grammar production that parses all alternatives. The parse therefore proceeds without trouble, however in a subsequent analysis phase, possibly in an overload of Xtext's afterModelLinked you can exploit the fully superset-parsed source to decide which of the alternatives is actually appropriate and elaborate/rewrite the CS tree accordingly. You will find that this approach is taken to resolve some nasty characteristics of the OCL grammar. I pioneered the approach in [1] chapter 5 and so successfully produced what was, possibly still is, the only yaccable grammar for C++. It resolves the arithmetic < / template < ambiguity without predicates or backtracking..

This approach is aided by using an LALR parser so that conflicts are noisily revealed. For this, I use [2] to convert my Xtext grammar to LPG to get shift-reduce / reduce-reduce conflict reports. I also use a manually defined Ecore metamodel since I do not find the auto-generated Ecore flexible enough.

Regards

Ed Willink

[1] http://www.computing.surrey.ac.uk/research/dsrg/fog/FogThesis.pdf

[2] GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.xtext2lpg
Re: Workaround semantic predicates [message #1852574 is a reply to message #1851702] Tue, 24 May 2022 13:47 Go to previous message
Antonio Garmendia is currently offline Antonio GarmendiaFriend
Messages: 93
Registered: May 2014
Member
Hi,

Sorry for the late reply, but we were implementing/testing these things in Xtext taking into account your advice and also this answer from Denis [1].

An the end, we create several Xtext grammars and one Ecore [2]. One relaxed grammar and several specific grammars. Then, we implemented a validation rule (@Check method) that in some cases it will check the specific grammars. The code is something like this:

@Check
	public void checkPatternProperties2(PatternPropertiesReference ppr) {		
		if (ppr.getKey().contains("a")) {
			//Get the String from the node
			String pprString= NodeModelUtils.getTokenText(NodeModelUtils.getNode(ppr));
			//Create new ResourceSet and Resource
			ResourceSet reset = new ResourceSetImpl();
			Resource resource = reset.createResource(URI.createURI("platform:/plugin/sample.test8/example.mydsl9"));
			//Create the InputStream using the obtained String from the node
			InputStream in = new ByteArrayInputStream(pprString.getBytes());
			try {
				resource.load(in, reset.getLoadOptions());
			} catch (IOException e) {
				e.printStackTrace();				
			}
			//Get the errors & error(pprString, null)
			resource.getErrors();			
			//Get the new PatternProperties
			PatternProperties2 ppr2 = (PatternProperties2) resource.getContents().get(0);
			//Container		
			PatternProperties pprRoot = (PatternProperties) ppr.eContainer();						
			//Remove all elements
			pprRoot.getProperty().remove(ppr);
			//Add new one
			pprRoot.getProperty().add(ppr2);			
			}
	}


So, we create several Xtext grammars in the same project but these grammars rely on the same meta-model. Do you think that this code is somehow correct? Is what you expect?

The other question is regarding if we should remove the previous element and add the new one. Is this seem correct to you? It seems to us that in Xtext this does not work well in some cases (we are still doing some tests)

The final question is if you know some literature about this (besides your thesis). Would you advise us of any paper or book?

Thanks again.

Kind regards,
Antonio

[1] https://d.strumenta.community/t/xtext-workaround-to-perform-a-semantic-predicate/1568
[2] https://www.eclipse.org/forums/index.php/m/1852106/#msg_1852106
Previous Topic:Xtext 2.27.0.M3 is out
Next Topic:Xtext grammar for SQL
Goto Forum:
  


Current Time: Mon Oct 03 01:13:03 GMT 2022

Powered by FUDForum. Page generated in 0.02254 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top