JSR 188 Comments

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.

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

Will JSR188 provide methods like getDefaultProfileValue(xxx), 
getProfileDiffValues(xxx) ?

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.

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.

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.

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 ?

Stephane boyera, W3C
Kazuhiro Kitagawa, W3C

Received on Monday, 26 May 2003 23:10:02 UTC