- From: Luu Tran <Luu.Tran@Sun.COM>
- Date: Wed, 18 Jun 2003 11:32:20 -0700
- To: boyera stephane <boyera@w3.org>
- Cc: "'Kazuhiro Kitagawa'" <kaz@w3.org>, jsr-188-eg@jcp.org, www-mobile@w3.org
Hi Stephane, Thanks for the clarification. The JSR 188 EG has considered these issues further. Please see below our responses. Thanks, Luu boyera stephane wrote: > We don't agree here. The discussion related to the references you are > providing was about "cameleon" properties: properties changing their > meaning according to the component they are belonging to. It is agreed > that this usage should be avoided. Our comments is not on these kinds of > properties, but on properties with the exact same meaning and semantic > on all components. The "vendor" property is one good example, even if it > disappeared later. We may imagine lots of properties like this (eg I > imagine all dublin core elements would fit in this category). > > We do think that we should promote the reuse of such attibutes over > components. Forbiding that through the API seems to be a highly > restrictive behaviour. The JSR188 spec actually does support vocabularies containing multiple attributes with the same local name in different components. If a vocabulary with that feature is used, the API method Profile.getAttribute should not be used. Profile.getAttribute is a convenience method that should only be used for vocabularies with unique attributes across all components. The recommended way to access attributes is via the API method Profile.getComponent.getAttribute. We will add this explanation to make it clearer in the spec. > We still don't agree on the decision to make further restriction > compared to the cc/pp specification. It seems to us that this is to ease > the implementation. We recommend that, if you decide to keep this > restriction, you state in the document that > - this is a restriction added by jsr188 > - this restriction does not exist in the cc/pp spec > - there are existing implementations showing that this is not > requested to make a valid cc/pp implementation We've updated the specification to remove this conflict as you suggest. In the case when two attributes with the same URI are defined in a profile within different components, the API will make available both attributes as separate objects, and the Attribute.getComponent method will return different values for the two objects.
Received on Wednesday, 18 June 2003 14:31:31 UTC