The SDO 2.1 spec includes the following:
An API for accessing open content (extensions) to meta objects is added to
the Type and Property interfaces:
Object get(Property property);
List getInstanceProperties();
Their definition is the same as the same methods on DataObject. The
primary purpose of these methods is to retrieve facet constraints for
types defined in XML Schema. However, it can be used to access constraints
from other data sources as well as any open content added to meta objects
including the two standard meta data open content properties described in
the specification: JavaInfo & XMLInfo.
The appinfo will also look like an instance property so you can also
retrieve it like by calling type.getString("appinfo").
Fuhwei told me that he was going to look at prototyping this for Tuscany.
I'm not sure if he's started yet. The plan is to use EAnnotations to store
the "virtual" instance properties.
Frank.
"Yang ZHONG" <[EMAIL PROTECTED]> wrote on 09/07/2006 03:43:12
PM:
> Metadata annotations are critical to some users, here brainstorms how
SDO
> can provide such access.
> Design *and* implementation contributions/helps are very much
appreciated!
> Metadata annotations sometimes contain information/instructions critical
to
> Business Logic.
> If that should have been done or not, is not in the scope of this topic.
> This thread covers how SDO supports existed users to access metadata
> annotations.
>
> Another incentive to provide metadata annotations access,
> is other modeling frameworks have already done so,
> such as Java (5) provides AnnotatedElement for Class, Field and son on,
> and EMF provides EModelElement for EClassifier, EStructuralFeature and
so
> on.
>
> Maybe SDO can provide
> interface MetaData
> {
> Annotation[] getAllAnnotations();
> List<Annotation> getDeclaredAnnotations();
> }
> for Type
> Type extends MetaData
> and Property
> Property extends MetaData
>
> Here brainstorms Annotation:
> interface Annotation extends MetaData
> {
> String getSource();
> void setSource(String value);
>
> Map<String,Object> details();
> }
>
> e.g.
> <complexType name="MyType">
> <annotation>
> <appinfo source="mySource1">
> <myDataObject xmlns="..." .../>
> </appinfo>
> </annotation>
> <attribute name="myProperty">
> <annotation>
> <documentation source="mySource2">
> myDocumentation
> </documentation>
> </annotation>
> </attribute>
> </complexType>
>
> For "MyType"
> annotation.getSource() returns "mySource1"
> (DataObject)annotation.details().get("appinfo") returns myDataObject
> For "myProperty"
>
> annotation.getSource() returns "mySource2"
> (String)annotation.details().get("documentation") returns
> "myDocumentation"
>
> One design issue is if we should treat Annotation itself a MetaData,
> my personal preference is why not (and not a big deal) and I find myself
a
> buddy: EMF EAnnotation extends EModelElement.
> However I think there may be opinion(s) to make it less
powerful/flexible by
> not treating Annotation itself a MetaData.
>
> Another design issue which may be quite controversial,
> is if we should be smart by automatically converting
> <myDataObject xmlns="..." .../>
> to DataObject. Users can always use XMLHelper#load to manually covert if
> necessary anyway,
> not to mention users have the control of which scope to use registered
> Type to instantiate DataObject instance.
> (It may be ultimately convenient to provide a String version of
> XMLHelper#load)
>
> I lean not to automatically convert, for performance concern.
> (Worst scenario, users have to XMLHelper#save to get the String format!)
> Therefore
> Map<String,Object> details();
> may be changed to
> Map<String,String> details();
>
>
> Any volunteer(s) to contribute/help the design *and* implementation
please?
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
