Re : JSR 188 Comments

Hello Luu,

Thank you and all the expert group for your answer.

See inline our comments:

> > 1.  Does JSR-188 spec allow to retrieve CC/PP-default data ?
> 
> The API allows an application developer to find out if a particular
> attribute value is a default value (via Attribute.isDefault()) but if 
> the attribute value is overridden, then there is no way to 
> find out the 
> original default value.  We felt that this information is not 
> useful to 
> application developers.

Ok. As we are not application developers we are not the right people to
argue on this point.

> We agree that caching of defaults is useful.  We also note that the
> reference implementation will cache defaults accordingly.  However, 
> since this is a function of processors, processors already have 
> sufficient information to determine the default values.

Ok
 
> > Will JSR188 provide methods like getDefaultProfileValue(xxx),
> > getProfileDiffValues(xxx) ?
> 
> We don't believe this is a useful function for applications that use
> JSR188 processors, so we don't plan to add methods such as 
> these in the 
> API.  We note that processors are free to add such methods if 
> they are 
> useful for the processors.

Ok
 
> > Please note this doesn't  intend to mention about internal data
> > structure.
> > 
> > Section 1.2
> > 
> > Please add the participants list instead of choosing arbitrary some
> > companies.  Current DI WG members are: HP,  Nokia, Volantis Systems 
> > Ltd, MobileAware Ltd.,
> > SAP AG,     Sun Microsystems, NTT DoCoMo,  SBC, Sony Corp, Boeing
> > IBM,  Panasonic, Sky Think System, INRIA.
> 
> Thanks for the correction.  We will make this change in the
> next draft.

Thanks

> We note that there was recently a discussion regarding this
> at the W3C 
> [1] where it was concluded [2] that attributes should belong 
> to only one 
> component.  

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.
 
> We also point out that according to the latest
> UAProf spec 
> [3], UAProf's Vendor attribute only belongs to the HardwarePlatform 
> component.  The SoftwarePlatform component has an attribute 
> called OSVendor.

This is a decision made by the UAProf committee and we think that this
is not the right place to make comments on that point.

> We agree that it is possible and often desirable to use
> profiles based 
> on multiple vocabularies.  Our intent was not to forbid 
> processors from 
> handling profiles based on multiple vocabularies.  In fact, the 
> reference implementation will handle profiles based on multiple 
> vocabularies to some extent.  For example, it is possible to retrieve 
> all of the components contained in a profile, regardless of 
> vocabulary, 
> by calling Profile.getComponents().

Ok
 
> However, we believe that further work is required in this
> area as it is 
> unclear from the CC/PP and UAProf specs what a processor should do if 
> two vocabularies define the same component differently.  In 
> the interest 
> of quickly producing a 1.0 version of this spec, we decided to defer 
> specifying the handling of profiles based on multiple 
> vocabularies to a 
> later release.

Ok.  All your explanation is valuable and help us understanding the
choices you made, and we agree with them. However, we recommend that you
mention all these explanations in the document, so that people would
know what's going on exactly, and would not make the assumption that the
multiple vocabularies are not acceptable for now and the future.
 
> JSR188 currently specifies that Attribute.getName returns only the
> fragment part of an attribute URI, e.g. "BitsPerPixel" for the UAProf 
> attribute 
> "http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#B
> itsPerPixel". 
> The relationship to the component is returned by 
> Attribute.getComponent.  This reinforces the assumption above that 
> attributes should be in only one component.

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

Best Regards

Stephane boyera, W3C
Kazuhiro Kitagawa, W3C

Received on Thursday, 5 June 2003 09:33:44 UTC