W3C home > Mailing lists > Public > public-media-annotation@w3.org > May 2010

Re: Re: ACTION-255

From: StrassnerˇˇJohn Charles <johns@postech.ac.kr>
Date: Thu, 6 May 2010 08:30:08 +0900 (KST)
Message-ID: <26305968.1273102209292.JavaMail.root@mail1.postech.ac.kr>
To: Felix Sasaki <felix.sasaki@fh-potsdam.de>, Joakim S?derberg <joakim.soderberg@ericsson.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>

.Bold { font-weight: bold; }
.Title { font-weight: bold; font-size: 18px; color: #cc3300; }
.Code { border: #8b4513 1px solid; padding-right: 5px; padding-left: 5px;color: #000066; font-family: 'Courier New' , Monospace;background-color: #ff9933; }

Hi Joakim,



First, I agree with Felix. Second, with my hat as future Editor on, I'd like to tighten the language a little. There are, imho,&nbsp;four things that can be improved.



line 1:

Change &quot;Annotaions&quot; to &quot;Annotations&quot;



line 3: 

This refers to specificationS, whereas the lines prior do not imply multiple specifications. See below for fix.



line 4:

This again refers to specificationS, but it is unclear if all specifications have to change in sync or not, and what happens if one changes and another doesn't. See below for fix.



line 5-6:

Change &quot;results in non-backwardly compatible changes from&quot; to&nbsp; &quot;result in changes that are not backward compatible with..&quot;



For the second and third problems, I'd recommend text as follows:


&quot;The W3C Media Annotations Working Group has defined a namespace URI, ma-ont, for use with the Ontology for Media Resource 1.0. As&nbsp;specifications that use this&nbsp;namespace URI progress through the&nbsp;standardization process, it is important that&nbsp;each subsequent revision of specifications that use this namespace MUST use the same namespace URI. However, should one or more specifications that use this namespace URI revert to Working Draft status during the standardization process, and a subsequent revision, published as a Working Draft (WD), Candidate Recommendation (CR) or Proposed Recommendation (PR) draft, result in changes that are not backward compatible with the original specifications, the namespace URI (ma-ont) MAY be changed.&quot;



Note carefully the insertion of the word &quot;MUST&quot; (see definition according to RFC 2119 below). This could be weakened to SHOULD if desired; however, SHOULD means that implementations would not have to use ma-ont, and imho, interoperability would be much harder to achieve.



Thoughts?



Text from RFC 2119:

1. MUST&nbsp;&nbsp; This word, or the terms &quot;REQUIRED&quot; or &quot;SHALL&quot;, mean that the

&nbsp;&nbsp; definition is an absolute requirement of the specification.



2. MUST NOT&nbsp;&nbsp; This phrase, or the phrase &quot;SHALL NOT&quot;, mean that the

&nbsp;&nbsp; definition is an absolute prohibition of the specification.



3. SHOULD&nbsp;&nbsp; This word, or the adjective &quot;RECOMMENDED&quot;, mean that there

&nbsp;&nbsp; may exist valid reasons in particular circumstances to ignore a

&nbsp;&nbsp; particular item, but the full implications must be understood and

&nbsp;&nbsp; carefully weighed before choosing a different course.



4. SHOULD NOT&nbsp;&nbsp; This phrase, or the phrase &quot;NOT RECOMMENDED&quot; mean that

&nbsp;&nbsp; there may exist valid reasons in particular circumstances when the

&nbsp;&nbsp; particular behavior is acceptable or even useful, but the full

&nbsp;&nbsp; implications should be understood and the case carefully weighed

&nbsp;&nbsp; before implementing any behavior described with this label.



5. MAY&nbsp;&nbsp; This word, or the adjective &quot;OPTIONAL&quot;, mean that an item is

&nbsp;&nbsp; truly optional.&nbsp; One vendor may choose to include the item because a

&nbsp;&nbsp; particular marketplace requires it or because the vendor feels that

&nbsp;&nbsp; it enhances the product while another vendor may omit the same item.

&nbsp;&nbsp; An implementation which does not include a particular option MUST be

&nbsp;&nbsp; prepared to interoperate with another implementation which does

&nbsp;&nbsp; include the option, though perhaps with reduced functionality. In the

&nbsp;&nbsp; same vein an implementation which does include a particular option

&nbsp;&nbsp; MUST be prepared to interoperate with another implementation which

&nbsp;&nbsp; does not include the option (except, of course, for the feature the

&nbsp;&nbsp; option provides.)



best regards,

John



Prof. John Strassner, Ph.D.

Head, Autonomic Research

Professor, Division of IT Convergence Engineering

Pohang University of Science and Technology

Pohang, Republic of Korea


johns@postech.ac.kr

&nbsp;


--- Original Message ---


From : 
&quot;Felix Sasaki&quot;&lt;felix.sasaki@fh-potsdam.de&gt;


To : 
&quot;Joakim S?derberg&quot;&lt;joakim.soderberg@ericsson.com&gt;


Date : 
2010/05/06 Thursday AM 12:43:44


Subject : 
Re: ACTION-255



Hi Joakim,




2010/5/5 Joakim S?derberg 
&lt;
joakim.soderberg@ericsson.com
&gt;






Dear all,


Here is a suggestion for text concerning mawg namespace and ma prefix:


?


?


Media Annotations Namespace: 
http://www.w3.org/ns/ma-ont


?


The &quot;ma&quot; abbreviation is a prefix for the namespace (
http://www.w3.org/ns/ma-ont
) which identifies the &quot;Ontology for Media Resource 1.0&quot;.


?


?


Stability of this namespace URI:


?


It is the intent of the W3C Media Annotaions Working Group that the Ontology for Media Resource 1.0 namespace URI will not change arbitrarily with each subsequent revision of the corresponding Ontology document as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a WD, CR or PR draft, results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification, the namespace URI will be changed accordingly.









I would change &quot;will be changed accordingly&quot; to &quot;may be changed&quot;, since &quot;ma-ont&quot; is a nice prefix, and we don't want to force ourself to give it up.



Felix



?






?


?







Received on Wednesday, 5 May 2010 23:30:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 5 May 2010 23:30:46 GMT