[rfc 208] Support extension attributes in metatype annotations

[bjhargrave]

Original bug ID: BZ#2575 From: David Jencks <djencks@us.ibm.com> Reported version: R6

[bjhargrave]

Comment author: David Jencks <djencks@us.ibm.com>

As a matter of principle, the metatype annotations ought to be able to generate any valid metatype xml. It is very straightforward to support extension attributes, so I think we should. I don't know of a way to support extension elements, so I'm not going to suggest supporting them. Also, the eclipse metatype implementation appears to support generic extension attributes, but I don't know of any implementation that uses extension elements.

I propose a new annotation:

@ Retention(RetentionPolicy.CLASS) public @ interface Extension {

/**
 * URI of the extension attributes
 */
String namespaceURI();

/**
 * prefix to use for this URI
 */
String prefix();

/**
 * attributes in key=value format, similar to the property element in DS
 * Component annotation, but without the types.
 */
String[] attributes() default {};

}

and adding this element to OCD and AD annotations:

/**
 * Extension attributes for this OCD, sorted by extension URI
 */
Extension[] extension() default {};

Each Extension instance would result in adding the URI namespace to the generated metatype document, and a = string would be added as an xml attribute like :=""

Some validation would be appropriate to make sure this translates into one valid xml attribute, and some escaping might be needed for xml-meaningful characters.

[bjhargrave]

Comment author: @bjhargrave

(In reply to David Jencks from comment BZ#0)

@ Retention(RetentionPolicy.CLASS) public @ interface Extension {

/**

• URI of the extension attributes */ String namespaceURI();

  /**

• prefix to use for this URI */ String prefix();

We should not allow this. The prefix is just a shorthand for the namespace and the annotation processor should be free to select any available prefix.

/**

• attributes in key=value format, similar to the property element in DS
• Component annotation, but without the types. */ String[] attributes() default {};

}

and adding this element to OCD and AD annotations:

/**

• Extension attributes for this OCD, sorted by extension URI */ Extension[] extension() default {};

If we go this far, why not allow this for any annotation processor which generates XML, like the DS annotations?

Some validation would be appropriate to make sure this translates into one valid xml attribute, and some escaping might be needed for xml-meaningful characters.

We can still end up generating invalid xml documents. Unless the tool (e.g. bnd) validates the specified attribute value against the namespace's schema (which bnd does not have). For example, the namespace could require the size attribute to have a positive integer value. But we would pass "size=foo" or "size=0" right through to the generated XML since the tool does not have any way to validate the value is valid for the namespace.

Currently we know that the tool must always generate a valid document since it only writes content in one namespace that we understand. If we open up to write content under any namespace, we will never know if the resulting document is valid.

So I don't think we should add this to the spec. If people have extension, they can develop their own annotation for which the tools understand the namespace and can generate valid documents.

[bjhargrave]

Comment author: @bjhargrave

CPEG call: We decided not to make this change to the spec at this time. The proposal is to work this idea in bnd as a bnd annotation. After some practical experience, it may make sense to bring this back to OSGi for possible inclusion in a spec.