Community
Participate
Working Groups
There are already requests for extending OCL on the TMF newsgroup. Extending the grammar is easy; just copy e.g. CompleteOCL's extension. Using the Xtext CST is hard. Provide: 1) API to faciliate persistence of the OCL CST as text 2) Tooling/API to faciliate conversion of the embedded OCL CST to an embedded AST 3) Tutorial and documentation.
Ed, This is going to be very useful. My specific use case is to actually only use the OCL "object navigation capabilities" for Objects and Collections. The incremental grammar on top, would then allow operations on the returned objects. To make it more concrete, the usage is actually something like formula's in excel, OCL would provide the access to the cells (objects), and the arithmetic grammar on top would do calculations and write the result. Perhaps for my case, I can simply (Copy the navigation part from the ocl essential.xtext).
Hey! Is there any update on this bug? I want to integrate/use OCL grammar in my Xtext grammar so that I can write OCL constraints in my DSL. I came across this link. Since this bug is very old (2011). I think there might be some way now to do so? /Yash
There has been progress and from an optimistic perspective it is already there; CompleteOCL, OCLinEcore, OCLstdlib, QVTc, QVTi, QVTr and a research MiniOCL all extend EssentialOCL and as a consequence have removed many impediments to re-use. However this bug should perhaps be retitled "... easily re-useable", since re-use is really only possible by someone with good Java skills, considerable determination and probably some guidance from me. Currently I continue to recommend that users seriously consider Xbase with its underlying Java characteristics and consequently much better Xtext integration before committing to an EssentialOCL extension. MiniOCL was part of research to automate the CS2AS bridge. This produced some additional CompleteOCL-based tooling, but it has not yet been exploited. Now that QVTr is getting viable some of the inconveniences of the CompleteOCL-based can vanish. One day, very large parts of OCL and QVTd will be auto-generated from their specification models at which point an extension will just need to provide (modified) specification models of their variant language. The tooling is nearly there and is being debugged for ATL2QVTr.
