Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL validation example violates extension point schema
OCL validation example violates extension point schema [message #62049] Tue, 09 September 2008 11:31 Go to next message
Eclipse UserFriend
Originally posted by: aprice.spamnot.tibco.com

Good day,

The org.eclipse.emf.validation.examples.ocl plug-in violates the
org.eclipse.emf.validation.constraintProviders extension point schema, by
providing an illegal 'ocl' child element and an illegal 'category'
attribute. The following markers show up against the plugin.xml in the
Problems View:

- Element 'ocl' is not legal as a child of element 'constraintProvider'.
plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in Problem
- Illegal attribute 'category' plugin.xml
org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem

I was able to achieve the same results without violating the extension point
schema by using a minor variation of the OCLConstraintProvider class and the
following extension:

<constraintProvider
class="com.example.validation.internal.ocl.OCLConstraintProvider ">
<package namespaceUri="http://www.example.com/model/>
<constraints
categories="com.example.validation.category.ocl">
<include
path="constraints/example.ocl">
</include>
</constraints>
</constraintProvider>

BTW the ext. pt. schema doc says that
constraintProvider/constraints/include@path is for 'Internal use only', but
the markup is semantically clearer than the current example and seems to
work fine.

Anyone have any comments?

Thanks,

Adrian Price
Senior Architect (Presentation Technologies)
TIBCO Software, Inc.
Re: OCL validation example violates extension point schema [message #62072 is a reply to message #62049] Tue, 09 September 2008 12:00 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: aprice.spamnot.tibco.com

Sorry, I realised I should have posted this to the EMF newsgroup. Done.

--A

"Adrian Price" <aprice@spamnot.tibco.com> wrote in message
news:ga5mqs$lp8$1@build.eclipse.org...
> Good day,
>
> The org.eclipse.emf.validation.examples.ocl plug-in violates the
> org.eclipse.emf.validation.constraintProviders extension point schema, by
> providing an illegal 'ocl' child element and an illegal 'category'
> attribute. The following markers show up against the plugin.xml in the
> Problems View:
>
> - Element 'ocl' is not legal as a child of element 'constraintProvider'.
> plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in Problem
> - Illegal attribute 'category' plugin.xml
> org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem
>
> I was able to achieve the same results without violating the extension
> point schema by using a minor variation of the OCLConstraintProvider class
> and the following extension:
>
> <constraintProvider
>
> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
> <package namespaceUri="http://www.example.com/model/>
> <constraints
> categories="com.example.validation.category.ocl">
> <include
> path="constraints/example.ocl">
> </include>
> </constraints>
> </constraintProvider>
>
> BTW the ext. pt. schema doc says that
> constraintProvider/constraints/include@path is for 'Internal use only',
> but the markup is semantically clearer than the current example and seems
> to work fine.
>
> Anyone have any comments?
>
> Thanks,
>
> Adrian Price
> Senior Architect (Presentation Technologies)
> TIBCO Software, Inc.
>
Re: OCL validation example violates extension point schema [message #62096 is a reply to message #62072] Tue, 09 September 2008 13:33 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Adrian,

The "include" was intended for use by the XML constraint provider that
has since been deprecated, which expected more XML conforming to the
same extension-point schema. I'm not sure that overloading it is the
right solution.

I was thinking about this some time ago, and would incline more to
defining some kind of generic name-value parameter schema that leaves
the interpretation to the constraint provider. What would you think of
that? It is certainly worth raising a bug for this; it's not so nice to
have an example that is ahead of the extension-point schema's capability
of expression.

e.g.

<constraintProvider

class="com.example.validation.internal.ocl.OCLConstraintProvider ">
<package namespaceUri="http://www.example.com/model/>
<configuration>
<param
name="categories"
value="com.example.validation.category.ocl"/>
<param
name="path"
value="constraints/example.ocl"/>
</configuration>
</constraintProvider>

Cheers,

Christian


Adrian Price wrote:
> Sorry, I realised I should have posted this to the EMF newsgroup. Done.
>
> --A
>
> "Adrian Price" <aprice@spamnot.tibco.com> wrote in message
> news:ga5mqs$lp8$1@build.eclipse.org...
>> Good day,
>>
>> The org.eclipse.emf.validation.examples.ocl plug-in violates the
>> org.eclipse.emf.validation.constraintProviders extension point schema, by
>> providing an illegal 'ocl' child element and an illegal 'category'
>> attribute. The following markers show up against the plugin.xml in the
>> Problems View:
>>
>> - Element 'ocl' is not legal as a child of element 'constraintProvider'.
>> plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in Problem
>> - Illegal attribute 'category' plugin.xml
>> org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem
>>
>> I was able to achieve the same results without violating the extension
>> point schema by using a minor variation of the OCLConstraintProvider class
>> and the following extension:
>>
>> <constraintProvider
>>
>> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
>> <package namespaceUri="http://www.example.com/model/>
>> <constraints
>> categories="com.example.validation.category.ocl">
>> <include
>> path="constraints/example.ocl">
>> </include>
>> </constraints>
>> </constraintProvider>
>>
>> BTW the ext. pt. schema doc says that
>> constraintProvider/constraints/include@path is for 'Internal use only',
>> but the markup is semantically clearer than the current example and seems
>> to work fine.
>>
>> Anyone have any comments?
>>
>> Thanks,
>>
>> Adrian Price
>> Senior Architect (Presentation Technologies)
>> TIBCO Software, Inc.
>>
>
>
Re: OCL validation example violates extension point schema [message #62118 is a reply to message #62096] Tue, 09 September 2008 17:53 Go to previous message
Eclipse UserFriend
Originally posted by: aprice.spamnot.tibco.com

Hi Christian,

Thanks for the quick response. Yes, your point re. overloading deprecated
schema elements taken entirely. In fact, I am just writing code to load any
additional constraints from EAnnotations on the EPackages registered for the
constraintProvider/package@namespaceURI s and am wondering how to assign
them to a category. The generic name-value pair solution you propose would
be ideal. I shall log an enhancement request.

Cheers,

--A


"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:ga5tup$96q$1@build.eclipse.org...
> Hi, Adrian,
>
> The "include" was intended for use by the XML constraint provider that has
> since been deprecated, which expected more XML conforming to the same
> extension-point schema. I'm not sure that overloading it is the right
> solution.
>
> I was thinking about this some time ago, and would incline more to
> defining some kind of generic name-value parameter schema that leaves the
> interpretation to the constraint provider. What would you think of that?
> It is certainly worth raising a bug for this; it's not so nice to have an
> example that is ahead of the extension-point schema's capability of
> expression.
>
> e.g.
>
> <constraintProvider
>
> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
> <package namespaceUri="http://www.example.com/model/>
> <configuration>
> <param
> name="categories"
> value="com.example.validation.category.ocl"/>
> <param
> name="path"
> value="constraints/example.ocl"/>
> </configuration>
> </constraintProvider>
>
> Cheers,
>
> Christian
>
>
> Adrian Price wrote:
>> Sorry, I realised I should have posted this to the EMF newsgroup. Done.
>>
>> --A
>>
>> "Adrian Price" <aprice@spamnot.tibco.com> wrote in message
>> news:ga5mqs$lp8$1@build.eclipse.org...
>>> Good day,
>>>
>>> The org.eclipse.emf.validation.examples.ocl plug-in violates the
>>> org.eclipse.emf.validation.constraintProviders extension point schema,
>>> by providing an illegal 'ocl' child element and an illegal 'category'
>>> attribute. The following markers show up against the plugin.xml in the
>>> Problems View:
>>>
>>> - Element 'ocl' is not legal as a child of element 'constraintProvider'.
>>> plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in
>>> Problem
>>> - Illegal attribute 'category' plugin.xml
>>> org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem
>>>
>>> I was able to achieve the same results without violating the extension
>>> point schema by using a minor variation of the OCLConstraintProvider
>>> class and the following extension:
>>>
>>> <constraintProvider
>>>
>>> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
>>> <package namespaceUri="http://www.example.com/model/>
>>> <constraints
>>> categories="com.example.validation.category.ocl">
>>> <include
>>> path="constraints/example.ocl">
>>> </include>
>>> </constraints>
>>> </constraintProvider>
>>>
>>> BTW the ext. pt. schema doc says that
>>> constraintProvider/constraints/include@path is for 'Internal use only',
>>> but the markup is semantically clearer than the current example and
>>> seems to work fine.
>>>
>>> Anyone have any comments?
>>>
>>> Thanks,
>>>
>>> Adrian Price
>>> Senior Architect (Presentation Technologies)
>>> TIBCO Software, Inc.
>>>
>>
Previous Topic:OCL parsing invariants
Next Topic:[Announce] MDT OCL 1.2.2 M200809101600 is available
Goto Forum:
  


Current Time: Tue Dec 23 01:48:44 GMT 2014

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

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