Re: [www-mobile] <none>

Kazuhiro Kitagawa schrieb:
> 
> Hello IG members,
> 
> In these days, WAP Forum published several specifications.
> These includes:
>    WML 2.0,
>    WAP Media Type
>    WAP CSS
>    UA Prof &
>    WAE.
> 
> The documents are available at:
>   http://www.wapforum.org/what/review.htm
> 
> Please see and review them.
> 
> Best regards,
> 
> -kaz
> --
> Kazuhiro Kitagawa    W3C Device Independence Activity Lead
>                      Mobile IG staff contact

Hi,

I was reveiwing UA-Prof new specification these days and I found some
points that could be discussed here.  First of all, I would like to
congradulate the authors of this specifictaion for the good job.  It
is well-structured, consistent, and unambiguous.  For example, for the
first time I could clearly recognize the differences between
ccpp:Component as an abstract class (of which prf:HardwarePlatform,
prf:SoftwarePlatform, etc. are subclasses) and ccpp:component as a
property for resources of type ccpp:Client-profile (in order to bind
component descriptions to a profile).  BTW, I don't understand why the
class name is not ccpp:ClientProfile instead of ccpp:Client-profile.

Remark: I tried to access the last version of CC/PP schema but access
was denied, so I'm using my printed version of Jan 29, 2001 for this
discussion.  

Now to the CC/PP-related points:

. CC/PP defines a ccpp:defaults property for resources of type
ccpp:Component.  Here I miss the same property for resources of type
ccpp:ClientProfile!  For example, the vendor of a PDA could provide
its CC/PP-Profile in one single document consisting of descriptions
about, say, both HardwarePlatform and SoftwarePlatform.  Why is the
vender forced to provide separate documents one for each component?  I
know that having defaults at component level leads to more
shareability, e.g. when two different PDA models have the same
SoftwarePlatform but different HardwarePlatforms.  But for me as
someone who uses a PDA with no additional features the whole profile
is identical with the one that could be provided by the vendor,
without any need to sew the different components in one single
profile; I could simply say:

:
<ccpp:ClientProfile rdf:about="http://.../MyProfile">
  <ccpp:defaults rdf:resource="..."/>
</ccpp:Profile>
:

. The ccpp:component property has currently only one domain, namely
ccpp:ClientProfile.  My suggestion is to allow it to be used also for
instances of ccpp:Component.  This way, we can build hierarchies of
components.  Example:  I have a class named TaskProfile as a subclass
of ccpp:ClientProfile and classes named TaskIdentity, TaskSchedule,
TaskLinks, and TaskPrefs all of which are subclasses of
ccpp:Component.  Instances of these classes can be used as components
of an instance of TaskProfile.  An instance of TaskPrefs can have
again several components, one of which could be an instance of
NotificationPrefs (NotificationPrefs is a subclass of
ccpp:Component).  The URIs for these components within a profile
addressed by "http://.../MyTask-1" could be constructed this way:

http://.../MyTask-1#TaskPrefs
http://.../MyTask-1#TaskPrefs.NotificationPrefs

and assuming that NotificationPrefs has a property named
"notificationType", I can write a CC/PP-profile for MYTask-1 this way:

:
<myns:TaskProfile rdf:about="http://.../MyTask-1">
  <ccpp:component>
    <myns:TaskIdentity rdf:about="http://.../MyTask-1#TaskIdentity">
      :
    </myns:TaskIdentity>
  </ccpp:component>
  <ccpp:component>
    <myns:TaskSchedule rdf:about="http://.../MyTask-1#TaskSchedule">
      :
    </myns:TaskSchedule>
  </ccpp:component>
  <ccpp:component>
    <myns:TaskLinks rdf:about="http://.../MyTask-1#TaskLinks">
      :
    </myns:TaskLinks>
  </ccpp:component>
  <ccpp:component>
    <myns:TaskPrefs rdf:about="http://.../MyTask-1#TaskPrefs">
      <ccpp:component>
        <myns:NotificationPrefs
rdf:about="http://.../MyTask-1#TaskPrefs.NotificationPrefs">
          <myns:notificationType>SMS</myns:notificationType>
          :
        </myns:NotificationPrefs>
      </ccpp:component>
      :
    </myns:TaskPrefs>
  </ccpp:component>
</myns:TaskProfile>
:


Now to the UA-Prof-related points:

. UA-Prof schema uses no rdfs:range, instead whenever they want to say
that a property accepts a resource of type rdf:Bag as its value, they
use an additional rdf:type for it, which is wrong (I guess).

. Use of capital letters at the beginning of attribute names is not
compatible with RDF conventions.

. The name 'BluetoothProfile' is, in my opinion, not a good choice. 
To my mind, the ending 'Profile' should be reserved for classes, like
ccpp:ClientProfile.

Regards,

-- Saied Tazari

Received on Wednesday, 1 August 2001 13:13:38 UTC