Issue #jsr188-01 Global Datatyping

Just changing the subject line to keep our process in order.

Brian

At 14:46 18/02/2003 +0000, Butler, Mark wrote:

>Dear Colleagues:
>
>JSR-188, the Java Specification Request for CC/PP processing,
>http://www.jcp.org/en/jsr/detail?id=188
>has examined the RDF last call working drafts published on the 23rd of
>January 2003. First, we commend the RDF WG for excellent work, and
>congratulate you on bringing your REC to last call. However we would like to
>raise an issue with the documents, concerning the adoption of local
>datatyping. Here we use the term "local datatyping" and "global datatyping"
>as proposed by Mike Dean
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jan/0173.html
>
>We agree with Mike's comments. Specifically the JSR-188 Expert Group would
>like to suggest that CC/PP definitely need "global" datatyping not "local"
>datatyping. As CC/PP is based on RDF, this means that RDF should provide
>some mechanism for global data typing. Adopting local datatyping will make
>CC/PP profiles unnecessarily verbose using up valuable network bandwidth. As
>one early adopter of CC/PP is UAProf which is aimed at wireless phone
>networks, profile verbosity is of a particular concern. In addition as Mike
>notes local datatyping also increases the potential for inconsistencies,
>which we found to be a considerable problem in the deployment of CC/PP and
>UAProf.
>
>Furthermore, we anticipate that local datatyping, which is clearly the wrong
>choice for CC/PP, will also be the wrong choice for other applications of
>RDF which require either
>1. require RDF/XML to be entered by hand, due to the increased risk of
>inconsistencies or
>2. for RDF/XML documents to be exchanged within protocols, due to increased
>document verbosity.
>
>Therefore we would like to raise the issue that we think the RDF core
>working group should reconsider its position on datatyping.
>
>Mark Butler, Hewlett Packard
>Luu Tran, Sun Microsystems
>Andreas Schade, IBM
>Jason Williams
>Reto Hermann, IBM
>Rotan Hanrahan
>Stan Wiechers
>Steve Geach, Elata plc