Am 10.01.2013 um 17:14 schrieb alexander.ber...@finnova.ch
alexander.ber...@finnova.ch:
That's a good question.
I think in terms of an API for accessing extra XML attributes, chances are
good that such an API could
be standardized (at least technically). But in terms of the specific extra
XML attributes I see no way to
get them standardized. And I guess that is the reason why the XSD (XML
Schema) for the metatype
descriptions allows for extra attributes (which reside in another XML
namespace). Maybe someone that
has worked on the specification might clarify what the intention about
allowing the extra attributes was.
Originally the idea was, that the same XML files would be used for metatype
descriptors and other applications. Which is why it is lenient to other data.
Unless I know more about the matter I long for the following:
1. Anybody can enrich the metatype descriptions with his own
(specific/individual) metadata.
The current specification supports this by allowing extra XML attributes
that reside in another namespace (##other).
2. An API to list respectively retrieve those extra attributes. And ideally
such an API could become part of the
metatype specification (new methods on the already existing interfaces or
on new sub-interfaces).
Please also consider that XML files are only one source for metatype
descriptors. Access is always through API which can also be implemented without
having XML.
One option I could conceive, though, would be that we extend the
AttributeDefinition interface with a new method:
String getExtraAttribute(String name);
which returns the named attribute.
WDYT ?
Regards
Felix
Regards
Alex
-Ursprüngliche Nachricht-
Von: Felix Meschberger [mailto:fmesc...@adobe.com]
Gesendet: Donnerstag, 10. Januar 2013 15:58
An: dev@felix.apache.org
Betreff: Re: Metatype Service - OptionalAttributes - extra XML attributes
with namespace support
Hi Alex,
Sorry, I missed your message from last week.
Am 10.01.2013 um 13:34 schrieb alexander.ber...@finnova.ch
alexander.ber...@finnova.ch:
I want to add some extra attributes to the metadata (XML) which will then be
used by a (special) administration console which knows about that extra
attributes. These extra attributes will be used to allow a more concise
representation of Configurations in the Graphical User Interface (GUI). For
example to show a value from a certain configuration property instead of its
PID in the GUI, as PIDs are quite meaningless to the average User.
Thanks. The reason for asking is, whether your use case is in fact something
that could be generalized to properly enhance the API. And thus to try to get
it into the specification.
Do you think such a generalization might be possible ?
Regards
Felix
Regards
Alex
--
finnova AG Bankware
Alexander Berger
Interface Development
Merkurstrasse 6
CH-5600 Lenzburg
Tel: +41 (0)62 886 48 07 (direkt)
Tel: +41 (0)62 886 47 47 (zentrale)
Fax: +41 (0)62 886 48 88
mailto:alexander.ber...@finnova.ch
http://www.finnova.ch
-Ursprüngliche Nachricht-
Von: Felix Meschberger [mailto:fmesc...@adobe.com]
Gesendet: Freitag, 4. Januar 2013 14:41
An: dev@felix.apache.org
Betreff: Re: Metatype Service - OptionalAttributes - extra XML
attributes with namespace support
Hi,
Am 04.01.2013 um 08:23 schrieb alexander.ber...@finnova.ch
alexander.ber...@finnova.ch:
Hi
I intend to use extra (optional) XML attributes with the Metatype Service.
Before commenting in detail, I would be interested to know what exactly you
want to achieve by using additional attributes on object class and attribute
definitions.
Regards
Felix
For this purpose I examined the
Felix metatype service implementation and found the class
org.apache.felix.metatype.OptionalAttributes,
which is extended by AD, OCD, ... . But unluckily this class is
neither inherited by LocalizedObjectClassDefinition nor by
LocalizedAttributeDefinition, which makes it quite useless for the moment.
Another Problem is that OptionalAttributes does not support XML namespaces
for the attribute names.
The underlying Map should use something like
javax.xml.namespace.QName as key and not just the name of the
attribute (String). Note, XML namespace support is crucial as extra XML
attribute have to be in a different (##other) namespace (see Metatype
Service Specifiaction (Version 1.2), section 105.9 XML Schema).
The above observations lead me to the following question:
1. Is it still a requirement for Felix subprojects to avoid
dependencies on packages like java.xml.** and rely on kxml2 instead?
a. If so, then I could try create a patch for metatype service which
will add support for extra XML attributes (including XML namespace support
but not using javax.xml.namespace.QName),
so that extra XML attributes could be retrieved from AD,
