RE: Core Vocabulary 1g : Editorial Comments (and regrets for Monday)

As the suggested alterations are editorial in nature, and generally dont look like they will cause any difficulty for the group at Monday's meeting, I believe we can come to agreement on these. If there are no substantive changes, then we can also resolve to publish. (I will take it from Jo's comment that he would support such a resolution.)
 
I tend to agree, on the basis that the number of aspects will always be far out-weighed by the number of properties, that a full chapter on aspects would be overkill. Subsection 3.1 is enough. However, one thing I would propose (to be consistent with properties) is that 3.1.1 and 3.1.2 be given anchors named #sec-aspect-device and #sec-aspect-webBrowser, which would make it easier to link ot them. Currently all property anchors are of the form #sec-property-PropertyID. If somebody later decides to create their own vocabulary they might be inclined to follow this example, and the anchoring would sttill work even if they decide to use a complicated chapter for aspects.
 
Regarding the Top N, it might be an interesting historical reference to show the motivation behind the vocabulary, but in formal terms (and in terms of our deliverables) we only need to explain the immediate process, and that is already covered in the document. If we were to go into history, where would we stop? The previous charter? The formation of the MWI? No, instead I am planning a major update of the public home page to contain important links to the major milestones (including the Top N) and links to other important references such as example implementations. Indeed, even after this group is closed, I expect the W3C custodians of the page to update it with new links to new implementations for some time afterwards.
 
Now, if we can just focus on finding error (including typos), we should be able to complete this. I think we've been working for enough months on the substance of the vocabulary to be confident that no further substantive changes are necessary.
 
---Rotan

________________________________

From: public-ddwg-request@w3.org on behalf of Jo Rabin
Sent: Thu 10/04/2008 07:18
To: public-ddwg@w3.org
Subject: RE: Core Vocabulary 1g : Editorial Comments (and regrets for Monday)




Some quick comments in line. I'm afraid I shall not be back at my desk till Wednesday next week now, so I won't be able to make any changes in time for Monday's call. I suggest you resolve to publish modulo any editorial changes needed.

Also my regrets for Monday.

Jo


> -----Original Message-----
> From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
> Sent: 09 April 2008 22:53
> To: Rotan Hanrahan; Jo Rabin; public-ddwg@w3.org
> Subject: RE: Core Vocabulary 1g : Editorial Comments
>
> --------
> Abstract
>
> "This document describes the Device Description Repository Core Vocabulary
> for Content Adaptation in the Mobile Web, described in the charter of the
> Device Descriptions Working Group, as well as the process by which the
> Vocabulary was defined"
>
> Introduction
>
> "This document identifies properties that are considered essential for
> adaptation of content in the mobile Web"
>
> + Comment: We need to be coherent in the nomenclature, if Mobile Web
> starts with upper case, it should start with upper case in every place
>

Yes agree.

> ----
>
> Introduction
>
> ... baseline Vocabulary for implementations of the Device Description
> Repository (DDR)
>
> + Comment: vocabulary shouldn't start with upper case letter (I think)

That's deliberate and consistent with DDR Simple API, same goes for Property and Aspect. This reflects a request originating with Jongpil in Seoul that terms used with a specific intent were highlighted.

> + Comment: people might misunderstand that there is unique DDR
>
> Suggested change:
>
> "for Device Description Repository Implementations"
>

Seems unlikely that this would be misunderstood but happy to change.

> -----
>
> Introduction
>
> "The Vocabulary makes reference to the ontology for the Web Delivery
> Context which is being developed by the W3C UWA Working Group [UWA-
> Ontology]."
>
> Comment: We are not actually cross referencing the DC Ontology. Shouldn't
> this text be dropped?
>

Yes

> ----
>
> Aspects of the Core Vocabulary
>
> "Work on Aspects of the Delivery Context continues, however, for the
> purposes of this Vocabulary two specific Aspects are identified."
>
> Comment: The phrase is unmeaningful to me ...
>

Replace with "This Vocabulary defines two aspects."

> -----
>
> I suggest that aspects have an specific chapter with an structure similar
> to the properties
>
> + Aspects
> |---- Device
> |--------ID
> |--------Description
>

I'd prefer not to do that. On the whole I regret having laid out the properties chapter in the verbose way it appears now. It could have been done with less of a waste of virtual paper and with a benefit to readability.

I feel that doing the same for Aspects would have little benefit and would be to "make a mountain out of a molehill". Naturally I will go with the group's inclination on this.

> -----
>
> Property Names and Property Value Types
>
> "The Property identifiers are associated with the namespace
> http://www.w3.org/2008/01/ddr-core-vocabulary"
>
> Comment: We need to say clearly that we are referring to the core
> vocabulary and that other vocabularies will also have its own IRI
> identifier

If that's not clear then it should be changed, of course, but this document is not about the generality of vocabularies, except where it describes how this one was compiled and says that other vocabularies could be compiled the same way. On reflection I am not sure that this adds to the usability of the document as if I were trying to find out what the properties of the core vocabulary are I would not want to read a discussion of how to "roll my own".

>
> -----
>
> When id's of aspects or properties are referenced in the text, they should
> be put between <code> tags, to allow a better internationalization of the
> document

perhaps

>
> -------
>
> In the examples, shouldn't we stay away from naming specific products,
> such as Mozilla Firefox?

How would you give an example without being specific?
>
> ----
>
> 4.5.2
>
> "Identified as an important Property by the DDWG in its Top N finding.
> Present in UAProf. Present (and used) in existing adaptation solutions"
>
> Comment: "Top N finding" and "UAProf" should be present as references in
> the document

Per the above, I am actually not sure that the history of the creation of the core vocabulary should actually be in this document. SO I don't know that the Top N finding is relevant and perhaps discussion of it should be removed.

UAProf, yup, sure, do you have a workable reference to it?


>
> -----
>
> 4.5.7
>
> "Needed if the screen orientation is rotated 90 degrees, in which case
> this Property would represent the width of the rotated screen."
>
> Comment: This sentence should be dropped as it is even wrong if the screen
> it's rotated this will represent the height of the display

Yes, I agree per "The total number of addressable pixels in the vertical direction of a rectangular display when held in its default orientation"

>
> --------------
>
> 4.6.4
>
> "Count the number of bits usable  ...."
>
> Comment: I suggest changing "usable" by "available"

Count the number of bits used for color definition?

>
> -------
>
> 4.10.3
>
> "Set of image formats a client supports as part of a Web page"
>
> Comment: Do we really need to say "as part of a Web page"

This, I believe, was to distinguish what can be displayed in the browser from what can be displayed through download.

Perhaps that explanation should be added.

>
> ---------
>
> 4.13.3
>
> "Which scripting languages are supported."
>
> Comment: It should say "Set of scripting languages a client supports" if
> we want to be coherent with the rest of the property description

"Set of scripting languages supported." Would be better as the reference to "client" is inconsistent with this being a webBrowser property.


>
> ----
>
> Nothing more for the moment

These editorial suggestions are of course welcome, but mostly could have been made at any time over the last 2 months. The fact that they come after a further editorial revision - where there was a specific call for revisions to be submitted prior to creating it - and could have been included in it, by and large, is a bit frustrating and the cause of needless work on my part and a possible frustrating further week's delay to publication.

I hope that people will feel moved to make their comments on the DDR-Simple-API asap and not leave till the last minute, on the basis that this too would cause needless delay, and quite likely needless effort on the group's part, not to mention mine.

Jo


> ________________________________________
> De: public-ddwg-request@w3.org [public-ddwg-request@w3.org] En nombre de
> Rotan Hanrahan [rotan.hanrahan@mobileaware.com]
> Enviado el: miércoles, 09 de abril de 2008 21:09
> Para: Jo Rabin; public-ddwg@w3.org
> Asunto: RE: Core Vocabulary 1g
>
> This will be on the agenda for next Monday, with the intention of
> proposing that it be moved forward for publication. Any remaining issues,
> if any, should be noted in advance on the mailing list, or otherwise we
> should assume there are no issues and we can resolve to publish.
>
> ---Rotan.
>
> ________________________________
>
> From: public-ddwg-request@w3.org on behalf of Jo Rabin
> Sent: Wed 09/04/2008 19:09
> To: public-ddwg@w3.org
> Subject: Core Vocabulary 1g
>
>
>
> Hi Folks
>
>
>
> Pls find the latest draft at
>
>
>
> http://www.w3.org/2005/MWI/DDWG/drafts/corevocabulary/080409
>
>
>
> hopefully we will resolve to make this official version of the W3C Note on
> Core Vocabulary.
>
>
>
> Use http://www.w3.org/2007/10/htmldiff to find differences between it and
> previous versions.
>
>
>
> Jo

Received on Thursday, 10 April 2008 08:58:33 UTC