Re: JSR 188 Comments

To: Kazuhiro Kitagawa <kaz@w3.org>
Cc: jsr-188-eg@jcp.org
Cc: Stephane Boyera <boyera@w3.org>
Cc: www-mobile@w3.org

Hi Stephane, Kaz,

Thank you very much for your comments on the public draft of JSR188. 
The JSR188 expert group has discussed these points.  Our conclusions are 
below.  Please let us know if you would like to discuss this further.

Thanks,
Luu Tran
JSR188 co-spec lead

Kazuhiro Kitagawa wrote:
> Dear Sir/Madam
> 
> Stephane Boyera and Kazuhiro Kitagawa W3C reviews JSR-188 specification
> and we have several comments on the specification.
> 
> Please find an attached review comments on JSR-188 specification.
> 
> -kaz
> -- 
> Kazuhiro Kitagawa W3C/Keio
> 
> -- 
> Generally, JSR specs are well defined to process CC/PP data.

Thank you.

> I have a couple of comments from engineering points of view, in 
> particular, CC/PP
> profile-default and profile-diff processing.
> 
> 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.

> I think CC/PP profile default and profile diff may have different 
> characteristics.
> 
> profile-default will be share several requests, but profile-diffs are 
> for individual requests.
> This means profile-default will have LRD and SS characteristics. But, 
> profile-diff will be short
> range dependent.
> 
> By considering above, profile-default and diff will be cached in 
> different manner.
> I think caching option will works more effectively if CC/PP processor 
> will be able to
> obtain cc/pp default vales easily.

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.

> 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.

> 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.

> Section 3.4.3
> I'm feeling that there are inconsistencies in the interface:
> AttributeDescription.getComponentDescription() makes the hidden
> hypothesis that an attribute can belongs to one component only. This is
> a restriction not present neither in CC/PP nor in Uaprof. On the
> contrary that one of the major reasons why RDF has been chosen. There
> are common characteristics among components that you would like to
> represent with the same attribute name. An example in the Uaprof
> vocabulary is Vendor which applies to both hardware and software platform.
> In a more general way, it seems to me that having the same attribute
> in multiple components to represent the same semantic information is a
> something we should promote for future designers of cc/pp vocabularies.
> It should appear in the "good practice" side, and defining different
> attributes for the same thing should be in the "bad practice" side.

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 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.

[1] http://lists.w3.org/Archives/Public/www-di/2003Apr/0016.html
[2] http://lists.w3.org/Archives/Public/www-di/2003Apr/0020.html
[3] http://www1.wapforum.org/tech/documents/WAP-248-UAProf-20011020-a.pdf

> Section 4.2.1 and 4.6
> There seems to be another hidden hypothesis here that the profile is
> just using one vocabulary.
> A profile may use multiple vocabularies managed through different
> namespaces. Like it should be possible to have in the same profile some
> components from UAProf profile, and some other components from another
> vocabulary like a possible future multimodal capabilities description
> vocab. That was another reason why RDF has been selected.

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().

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.

> Section 4.2.3
> Attribute.getName is described as returning an attribute name which is
> unique on the profile. Thus, it must contain the component name right ?
> This should be specified ?

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#BitsPerPixel". 
  The relationship to the component is returned by 
Attribute.getComponent.  This reinforces the assumption above that 
attributes should be in only one component.

> Stephane boyera, W3C
> Kazuhiro Kitagawa, W3C

Received on Monday, 2 June 2003 19:34:40 UTC