Hi Christian,
thanks for your suggestions. The implementation for the first part
(getUpperBound) of your point 1 is already available in the new api variant
of the SDOUtil [1] class (the old SDOUtil now being deprecated). Adding
getLowerBound() would be simple, but you may have noticed that there is
already a nod in that direction with the SDOUtil.isRequired() method, which
may serve your needs.
For point 2, I think you should be able to do
type.getInstanceProperties() and find the Property called "enumeration".
Then you can get the enumerations using that Property.
(see MetaDataInstancePropertiesTestCase [2])
For point 3, I think we could add something like this as an SDOUtil method,
but an interesting aspect of this would be describing exactly what it does.
It would be validating simple schema facet constraints, but it wouldn't be a
full schema validator. Some of the things it would be doing would be hard
to relate back to SDO concepts I think, I'd have to look in more detail to
get the full picture. However, if you opened a JIRA and were able to supply
a patch for this, I feel sure we could add it, with some description, and
perhaps a few words of warning that the behaviour is not always entirely
describable in SDO terms alone.
Regards, Kelvin.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOUtil.java
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/MetadataInstancePropertiesTestCase.java
On 11/06/07, Christian Landbo Frederiksen <[EMAIL PROTECTED]> wrote:
Hi
I have a couple of places where I go beyond the SDO classes and into
EMF, that I would to see included into some of the SDO utilities:
1. Upper and lower bound on properties where 'isMany' is true:
I have implemented it like this
public static int getUpperBound(Property property) {
return ((EStructuralFeature) property).getUpperBound();
}
public static int getLowerBound(Property property) {
return ((EStructuralFeature) property).getLowerBound();
}
The SDOUtil class seems a perfect place to put these.
2. The enumeration facet
I need to know whether a type has enumerated restrictions:
public static List<String> getEnumerationFacet(Type type) {
return
ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
}
3. Validation
I do validation using Diagnostic:
Diagnostic diagnostic = Diagnostician.INSTANCE.validate((EObject)
dataObject);
if (diagnostic.getSeverity() == Diagnostic.ERROR) {
.....
I haven't seen if SDO 2.1 has introduced other kind of validation of if
a funtionality is in the making...
/Chr
-----Original Message-----
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 8. juni 2007 19:02
To: [email protected]
Subject: Re: [SDO Java DISCUSS] Contents of the next SDO release
I'd like to draw the communities attention to this issue again please.
Thanks to David for responding with his requirements and with the fix
for
1223. I have some thoughts that I'm structuring at the moment on what's
important for a next release from my perspective that I'll post soon,
but
in general I'm just keen to get the good stuff that we have added
recently
out in a release that, as I said before from my perspective, warrants
the
title of "1.0". With the Summer holiday season coming up, I'd like to
do
this soon so that I can sun myself on a beach without that niggling
feeling
of things that ought to have been done ;-)
What say you we put a stake in the ground of aiming for a SDO 1.0
release to
be at the IPMC ratification stage by mid-July?
So to that end I ask again, if you have requirements that you feel are
fundamental to the next release please raise them now; with the caveat
of
course that the only way to be sure of getting your requirements into
the
release is to step forward and supply the fixes.
--
Kelvin.
On 23/05/07, David Adcox <[EMAIL PROTECTED]> wrote:
>
> Kelvin,
>
> I would like to see the multiple namepace issue resolved in the
> XSD2JavaGenerator tool. This issue is covered in JIRA 1223.
> Optionally, making it available to the plugin (JIRA 303) would be
> nice. JIRA 1143 is something that I need fixed, as well. So any
> focus that can be given to that prior to this release would be
> appreciated.
>
> In the spirit of cooperation, I'll be posting a first pass on 1223 a
> bit later in the week.
>
> Thanks,
> David
>
>
> On 5/21/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> With the beta1 release of SDO Java announced, I have begun thinking
about
> a
> next release which I believe can be given the version tag
1.0-incubator
> . We
> have full coverage of the 2.1 SDO spec in the trunk now, and we
currently
> have 33 open JIRAs.
>
>
>
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid
=12310210&status=1&status=3&status=4&component=12310660&component=123109
73&component=12310802&sorter/field=issuekey&sorter/order=DESC&sorter/fie
ld=components&sorter/order=ASC&sorter/field=priority&sorter/order=DESC
>
> Please give feedback on those issues which are important to you and,
if
> possible, step up to provide fixes for those issues.
>
> If we are to call this the 1.0 release then it ought to provide a
really
> good experience for the user. Please share your experiences about
using
> the
> beta1 release and make suggestions or contributions to improve the
next
> one.
> Aside from fixes to the code, key contributions would be to improve
the
> instructions, the samples and the documentation (we already have
> discussions going on about the shape of the release distributions on
> another
> thread).
>
>
> Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
