W3C home > Mailing lists > Public > public-annotation@w3.org > November 2016

RE: URGENT: bodyValue

From: Cole, Timothy W <t-cole3@illinois.edu>
Date: Fri, 11 Nov 2016 18:41:39 +0000
To: "Jett, Jacob Guy" <jjett2@illinois.edu>, Web Annotation <public-annotation@w3.org>
Message-ID: <EECC28A63F2ED74B8420079BBE599453617070F4@CITESMBX6.ad.uillinois.edu>
Apologies for missing this one ahead of today's call.  Not sure if I missed it by being fooled because it showed up in more than one annotation (albeit only 1 implementation), or if I just missed it because I prefer not to think about bodyValue.

Regardless, my recommendation would be to treat it the same as you are treating Choice-Target and Creator-Target. I believe this would be consistent with the decision of the WG earlier today and we should not invent a new pattern in spite of the temptation some of us may have to do so for this particular key.

So, move it to informative appendix or mark at risk for the CR extension - whichever it is you are doing for the other 2 features that do not yet have 2 implementations and are unlikely to get 2 next few weeks (in the latter case of marking it at risk, as you say, it will be moved before we enter PR unless another implementation turns up during the CR Extension).

For me, the fact that there is one implementation (as there is for Creator-Target) argues against jettisoning bodyValue from the document altogether, as does the fact that the WG discussed at length and in the end decided to include it.

Regarding Exit Criteria, I assume that today you are removing the exit criteria for Choice-Target and Creator-Target, and should do the same for bodyValue.

If marked at risk or relocated to an informative appendix now, would we have the option to consider dropping bodyValue altogether when we do finally move into PR (personally, I'd rather not do so at that point in time, but just asking).


Tim Cole

From: jgjett@gmail.com [jgjett@gmail.com] on behalf of Jacob Jett [jjett2@illinois.edu]
Sent: Friday, November 11, 2016 12:12
To: Web Annotation
Subject: Re: URGENT: bodyValue

I'm personally in favor of jettisoning it. However, if I understand correctly from today's call all four of the options you listed will cause some form of issue for exiting CR so...

I'm not certain what we can do. Ivan?



Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
School of Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164

On Fri, Nov 11, 2016 at 12:02 PM, Robert Sanderson <azaroth42@gmail.com<mailto:azaroth42@gmail.com>> wrote:

One of our exit criteria is:

    The bodyValue property of an Annotation.

However according to the report (http://td.spec-ops.io/test-results/annotation-model/all.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__td.spec-2Dops.io_test-2Dresults_annotation-2Dmodel_all.html&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=hWpKA6k6kL6R-zJULrRnnsHIkDHLL4O3FxqITgP9x_Q&s=5sUMaKzpEpcxswL_GxXUXMCUXRap4Xj4458dn-Zt8Xk&e=>), we have only one implementation of bodyValue (EF).  It's 1:4 in the annotation optionals section.

I don't believe we'll get a second implementation of it, so do we:

* Just remove the exit criterion, as it's an optional feature anyway
    -- But there's a lot of optional features that are still exit criteria
* Move the feature to an appendix, following Composite/List
    -- But it wasn't marked at risk like those classes
* Mark the feature at-risk and remove it before PR
    -- But we rejected this approach for the other features in the same state;
* Remove the feature completely
    -- But this would be a big change without formal discussion

My preference hasn't changed, which would be to remove it completely.  That we don't have implementations that use it, and we do have implementations that use TextualBody is evidence that the rationale for it (TextualBody is too hard) is unjustified.



Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049
Received on Friday, 11 November 2016 18:42:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC