W3C home > Mailing lists > Public > public-ddr-vocab@w3.org > October 2007

RE: [VOC] CoreVocabularySubmissions on the Wiki updated

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Tue, 2 Oct 2007 03:33:50 +0100
Message-ID: <D5306DC72D165F488F56A9E43F2045D301475475@FTO.mobileaware.com>
To: <public-ddwg@w3.org>
Cc: <public-ddr-vocab@w3.org>

As there have been substantive contributions to the vocabulary recently,
I think it appropriate that we discuss this week and formulate an
opinion by next week's call.

I noted the change made regarding the representation of supported image
formats. The proposal is a comma-separated list of predefined names. As
an API return result, this might be acceptable. As a vocabulary value, I
have strong doubts. A list that has to be further parsed is ill-advised.
I recall the problem with UAProf and the need to parse the screen-size
string. In the vocabulary, a list should be a real list, a set should be
a set. These are "first class" data types. In other words, don't think
of it as a String, but as a String[] or SetOfString.

It may be acceptable for the API to return the value as a
comma-separated list, if that's what developers demand. However, what
would developers likely do with this comma separated string? I can think
of two likely things:

1. They would parse the string, using the commas as delimiters, in order
to match the device's supported formats against the image resources
available to the server (or those it is capable of generating).

2. They would do a quick pattern match of the string to see if their
resource format is included therein.

In both cases, giving the developer an array or set directly would be
preferable, as it means the developer doesn't have to write the parsing
code. (I.e., one more mistake the developer won't be tempted to make.)

Consequently, my opinion is that the comma-separated list is
inappropriate for the vocabulary, and probably not as useful in the API
as a real array or set would be.

The values mentioned in the summary on the wiki look fine. As these will
all belong to values defined by the vocabulary, I'm assuming they will
all belong to the same "namespace". The proper identifier for each of
these values is a URI, in the vocabulary. Nevertheless, it makes sense
for the API to return these to the developer as simple strings, like
"png". In other words, the API can hide the vocabulary's complexity
involving unique namespaces and URIs.

We haven't figured out the vocabulary's URI mechanism yet, but the
discussion we had on last week's joint call has helped us move forward a
little [1].


[1] http://lists.w3.org/Archives/Public/public-ddwg/2007Oct/0007.html

-----Original Message-----
From: public-ddr-vocab-request@w3.org
[mailto:public-ddr-vocab-request@w3.org] On Behalf Of Andrea Trasatti
Sent: 01 October 2007 15:51
To: public-ddwg@w3.org
Cc: public-ddr-vocab@w3.org
Subject: [VOC] CoreVocabularySubmissions on the Wiki updated

I have updated the page [1] on the Wiki with the submissions received  
so far for the Core Vocabulary.
In the last group call [2] was agreed to move from single properties  
to sets of values. The updated page reflects this idea. I know the  
layout is fat from perfect, this is due limitation in the Wiki  
engine. Anyone who knows MoinMoin and wants to suggest a better  
layout is welcome.

We are looking for comments in the very short term to get to approval  

[1] http://www.w3.org/2005/MWI/DDWG/wiki/CoreVocabularySubmissions
[2] http://www.w3.org/blog/DDWG/2007/09/20/meeting_summary_17_sept_2007

Andrea Trasatti
Director of Device Intiatives mTLD

mTLD Top Level Domain Limited is a private limited company  
incorporated and registered in the Republic of Ireland with  
registered number 398040 and registered office at Arthur Cox  
Building, Earlsfort Terrace, Dublin 2.

The information contained in this message may be privileged and  
confidential and protected from disclosure. If the reader of this  
message is not the intended recipient, or an employee or agent  
responsible for delivering this message to the intended recipient,  
you are hereby notified that any dissemination, distribution or  
copying of this communication is strictly prohibited. If you have  
received this communication in error, please notify us immediately by  
replying to the message and deleting it from your computer.
Received on Tuesday, 2 October 2007 02:34:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:46 UTC