I would like to revive this thread. I have a need for the same thing, and for precisely the same reason as Alexander!
I also don't mind the proposed interface, however I have less need for supporting many namespaces as I believe that at least one specific to modeling the UI is really the key here. But the last suggestion would be fine to me! However, I do agree that no solution is complete without supporting MetaTypeProviders. I'll investigate the options there and see if I can propose something. - Ray On Fri, Jan 18, 2013 at 3:42 AM, <alexander.ber...@finnova.ch> wrote: > Hi > > Wakeup-Call :-). Has anybody a better idea or substantial arguments > against my last proposal? > > Regards, > Alex > > -----Ursprüngliche Nachricht----- > Von: alexander.ber...@finnova.ch [mailto:alexander.ber...@finnova.ch] > Gesendet: Montag, 14. Januar 2013 10:59 > An: dev@felix.apache.org > Betreff: AW: Metatype Service - OptionalAttributes - extra XML attributes > with namespace support > > Bridging the world of namespace-aware XML and not namespace-aware object > models like Java, where an object can only have one field (attribute) with > the same name, is quite difficult. In other words if we allow for multiple > namespaces for XML attributes (which at the moment is the case according to > the spec) then we must also adopt that concept of namespaces in the Java > object model. > > And as a note, (namespace) prefixes by them self are meaningless. They > only convey meaning if they are associated with a namespace. > > So we need a solution which is namespace-aware and not limited to, but > compatible to XML. In the light of this I suggest the following interface, > where "namespace" is now a generic concept (abstraction) and does not > necessarily stand for XML-namespaces per se. > > public interface ExtraAttributes { > > /** > * List the names of extra attributes for a given namespace. > * > * @param namespace the namespace for which to retrieve the names > of available attribute. > * > * @return an {@link Iterator} producing the {@link String}s of > the extra attribute names. > * for the given namespace. > */ > public Iterator<String> getExtraAttributeNames(String namespace); > > /** > * Retrieve the value of an extra attribute. > * > * @param namespace the namespace from which to retrieve the > attribute value. > * @param name name of the extra attribute, whose value should be > retrieved. > * @return the value of the extra attribute or <code>null</code> > if no attribute with > * that name exists. > */ > public String getExtraAttributeValue(String namespace, String > name); } > > What do you think. > > Regards > Alex > > -- > finnova AG Bankware > Alexander Berger > Software Architect > 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: Montag, 14. Januar 2013 10:39 > An: dev@felix.apache.org > Betreff: Re: Metatype Service - OptionalAttributes - extra XML attributes > with namespace support > > Hi > > QNAme is an XML-ism and the API is XML-free (as I said, use of XML is just > one way to back the API). So I am extremely reluctant to using QName > (regardless of whether we use javax.xml.QName or define our own QName > class). Always consider the case where an QbjectClassDefinition might be > backed by a MetaTypeProvider service and not XML. > > As for the interface (except QName question), I am fine. > > However, I could assume we could have the name, if it comes from XML, to > be something like > > {url}localname > > or > > prefix:localname > > And, of course, the {url} or prefix: prefix would be omitted for the > default namespace (empty string) or the namespace of the metatype > descriptor. > > Regards > Felix > > Am 14.01.2013 um 07:43 schrieb <alexander.ber...@finnova.ch> < > alexander.ber...@finnova.ch>: > > > O.K. I see. > > > > Then I would suggest to add something like the following interface to > AttributeDefinition and ObjectClassDefinition: > > > > public interface ExtraAttributes { > > > > /** > > * List the {@link QName}s of extra XML attributes. > > * > > * @return an {@link Iterator} producing the {@link QName}s of the > extra attributes. > > */ > > public Iterator<QName> getExtraAttributeNames(); > > > > /** > > * Retrieve the value of an extra XML attribute. > > * > > * @param name {@link QName} of the extra attribute, whose value > should be retrieved. > > * @return the value of the extra attribute or <code>null</code> > if no attribute with > > * that name exists. > > */ > > public String getExtraAttributeValue(QName name); } > > > > However, my initial question about QName and XML API support arises > > again as we are using QName here. Note, using just a String as > > argument to getExtraAttributeValue will not work, as several > > attributes with the same name but different Namespaces (prefixes) might > exist on the same Element. > > > > Regards > > Alex > > > > -- > > finnova AG Bankware > > Alexander Berger > > Software Architect > > 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: Samstag, 12. Januar 2013 22:15 > > An: dev@felix.apache.org > > Betreff: Re: Metatype Service - OptionalAttributes - extra XML > > attributes with namespace support > > > > > > 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, OCD, > ..., LocalizedObjectClassDefinition and LocalizedAttributeDefinition > instances. > >>>> b. If not, then I could try to create a similar patch as > described above (a) but using javax.xml.namespace.QName instead. > >>>> > >>>> Note, the class javax.xml.namespace.QName is part of JavaSE since > version 1.5 older versions as well as JavaME do not contain that class. > >>>> > >>>> Alex > >>>> > >>>> > >>> > >> > > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
