RE: datatypes: conversation with Mark Butler, chair of cc/pp

Patrick, Dan

Unfortunately I think we have jumped ahead a little in the argument here.
Some salient points:

1. CC/PP, by its charter has to be compatible with UAProf, a similar
standard for device profiling created by the OMA / WAP Forum
http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-20011020-a.pdf

UAProf is being deployed in the current generation of phones - here are some
example profiles
http://mobileinternet.ericsson.com/UAprof/T39.xml
http://mobileinternet.ericsson.com/UAprof/T68R1.xml
http://www.mitsubishi-telecom.com/profiles/eclipse.ua

For some background on CC/PP and UAProf, see
http://www.cooltown.hp.com/mpulse/0202-deli.asp

2. UAProf currently uses an outdated form of RDF. For example in UAProf it
is common

2.1 to omit namespaces before ID's or abouts

2.2 processors have to search for nodes via local ID's: for example UAProf
processors locate structures called components e.g.

 <prf:component>
 <rdf:Description ID="HardwarePlatform">
  <prf:ScreenSize>101x54</prf:ScreenSize> 
 </prf:component>

I think this is wrong - HardwarePlatform needs to be fully qualified to do
this e.g.

 <prf:component>
  <prf:HardwarePlatform rdf:ID="HardwarePlatform">
  <prf:ScreenSize>101x54</prf:ScreenSize> 
 </prf:component>   

2.3 the RDF Schemas used by UAProf contain lots of errors - see
http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#
http://www.wapforum.org/profiles/UAPROF/ccppschema-20000405#

For more details of these issues, see
http://www-uk.hpl.hp.com/people/marbut/someQuestionsOnCCPP.htm
http://www-uk.hpl.hp.com/people/marbut/deliverycontextFinal.html

3. I've been trying to get the WAP Forum to update UAProf spec so these
problems, particularly the problems with the Schemas are resolved. Currently
I have to distribute corrected versions of UAProf schemas with my CC/PP
processor instead of use the public versions of these schemas. I'm still in
discussion with the WAP Forum about this, but I am receiving a lot of
pushback because they are afraid these changes will break existing
implementations.

4. Some of the datatype proposals you are discussing will simply not work
with UAProf, and based on my experience in (3) I think it will be uphill
task to get the WAP Forum to change UAProf to reflect the datatype
proposals. Therefore I would suggest you need to think carefully about how
you are going to maintain backward compatibility with applications like
this.

Now in your replies, you focused on the use of XML Schema and I think that
is a side issue. CC/PP badly needs validation but I don't particularly care
how it is done. As I see it the primary issue here is any datatype changes
in RDF shouldn't break backward compatibility with CC/PP or UAProf, or if
they do there needs to be a clear work-around in place to overcome this. 

best regards

Mark H. Butler, PhD
W3C CC/PP Working Group Chair
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

> -----Original Message-----
> From: Brian McBride [mailto:bwm@hplb.hpl.hp.com]
> Sent: 14 August 2002 18:49
> To: RDF Core
> Cc: mark_butler@otter.hpl.hp.com
> Subject: datatypes: conversation with Mark Butler, chair of cc/pp
> 
> 
> I chatted with Mark Butler yesterday, including some discussion of 
> datatypes in cc/pp.
> 
> One of the ideas that Mark favours is to define an XML Schema 
> for the cc/pp 
> language.  This would enable:
> 
>    o validation of incoming cc/pp profiles to a server
>    o the use of default attributes to insert datatype 
> attributes such as 
> xsi:type="xsd:decimal" automatically, thus providing global implicit 
> datatyping in the parser.
> 
> Whilst not perfect, does this technique go some way towards 
> meeting the 
> need for global implicit datatyping.
> 
> Brian
>

Received on Thursday, 15 August 2002 10:34:50 UTC