- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 5 Aug 2016 18:09:24 +0200
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <3001116E-F7C1-45E2-95DE-8A3BB87A5B0F@w3.org>
Minutes of meeting are here:
https://www.w3.org/2016/08/05-annotation-minutes.html
Text version below.
Ivan
----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
[1]W3C
[1] http://www.w3.org/
Web Annotation Working Group Teleconference
05 Aug 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/08/05-annotation-irc
Attendees
Present
Shane McCarron, Ben De Meester, Rob Sanderson (azaroth),
Tim Cole, T.B. Dinesh, Paolo Ciccarese, Ivan Herman,
Benjamin Young (bigbluehat), Takeshi Kanai
Regrets
Chair
Rob Sanderson, Tim Cole
Scribe
bigbluehat, TimCole
Contents
* [3]Topics
1. [4]Minutes Approval
2. [5]Issues
3. [6]Testing
4. [7]Protocol Testing
5. [8]AOB?
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<azaroth> trackbot, start meeting
<azaroth> scribenick: bigbluehat
azaroth: going over the agenda
... there's been a flurry of i18n discussion
... we'll get some updates on testing
... if there are any demos, it'd be great to see them
... is there anything anyone would like to add?
TimCole: I have a couple questions for clarification about
model testing
azaroth: k. we'll run with what we have
Minutes Approval
<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are
approved:
[11]https://www.w3.org/2016/07/29-annotation-minutes.html
[11] https://www.w3.org/2016/07/29-annotation-minutes.html
<TimCole> +1
+1
<azaroth> +1
<takeshi> +1
RESOLUTION: Minutes of the previous call are approved:
[12]https://www.w3.org/2016/07/29-annotation-minutes.html
[12] https://www.w3.org/2016/07/29-annotation-minutes.html
<tbdinesh> +1
azaroth: any announcements?
Issues
<azaroth> I18n issue:
[13]https://github.com/w3c/web-annotation/issues/335
[13] https://github.com/w3c/web-annotation/issues/335
azaroth: we have one major issue
... hopefully people have been keeping up a little
... there was some discussion in the Social Web WG
... about how to resolve their I18N issues
... there was some suggestion that they consider how we solved
our I18N issues
... they disagreed, and have told us we shouldn't do it that
way either
... there are three folks from social and one person from
Europiana who feel we need to change our approach
... there are also two subsidiary issues that have come out of
it
... one that proposes getting rid of textDirection and instead
use Unicode characters
... and 337 around the carnality of processingLanguage
... We have to address them. the question is how.
... We did talk to the I18N folks, and this approach was OK
with them.
... reversing them would be tricky as they've not been marked
at risk
... and in my opinion we have not seen information that proves
they are actually not useful
... we could change how we've described them
... but we did go around several times with the I18N folks to
come to the descriptions that we do have
TimCole: one thing that got mentioned, is the assumption that
we are specifying client behaviours as well as the data
structures
... the issue of context arose around formatted language hints
... that an annotation creation agent could add about a
resource
... that might be useful
... and that allowing multiple languages listed made it less
useful
... so we added processingLanguage and textDirecton to help
... but then we've also stated that if the actual resource
states something different, that these can be considered as
overridden
... and these properties are meant to be used as hints
... since we're not specifying client behavior, I don't think
we should put anything heavier in place
... I'd propose some editorial revisions that clarify the
intended use, and clarify that we don't know how they'll be
used, but that we wanted them there as we felt they were useful
azaroth: format and language we can specify them on the
annotation that the client can expect these things, but we
can't guarantee
... maybe the name has changed or whatever else
... this is true with everything on the Web
... the canonical source is authoritative
... and it seems like a general principle
<PaoloCiccarese> +1
azaroth: in Section 2
... saying we're not trying to be authoritative
... you can add information as it's helpful, but if it's
contradicted by the source, then you should believe that source
ivan: I'm not deep into these topics, but we did have a very
long discussion with the real experts
... and with all my respect for the detractors, we've made our
decisions with the input of these experts
... and with that as background, we should not remove them
... unless they I18N folks ask that after all they would rather
we remove them
... as long as the I18N experts maintain their advice, we
should keep things as they are
<tbdinesh> +1
<azaroth> +1
ivan: I am not sure what exactly what the editorial explanation
like comments that we got
... until now the only thing I see as a cursory reading is
additional technical discussion
... and doesn't seem to result in a "please put this content in
this place in this way" sort of change
... and it's really just too late for this sort of editorial
usage commentary to be added to the spec
... So, unless the I18N experts suggest we change them, we
should make a resolution that we intend to keep them based on
their input
<ShaneM> +1
<tbdinesh> Unicode indicator will override. so not
contradicting anything
ivan: and that it's just too late in the process to add the
commentary
<azaroth> PROPOSED RESOLUTION: Unless the i18n group advise
otherwise, the WG will not remove textDirection and
processingLanguage from the model
<PaoloCiccarese> +1
<azaroth> +1
<tbdinesh> +1
<TimCole> +1
<ivan> +1
+1
<takeshi> +1
<bjdmeest> +1
<ShaneM> +1
PaoloCiccarese: so. I have a question.
... say they don't come back to us about it
... and that in a few months they come back and say that we
should change these?
ivan: this can happen to any feature in the document
<ShaneM> Errata is a way to capture information
ivan: it is a matter of at some point in time we'll have to
figure out an errata mechanism
... if it happens at all, it would be handled as an errata
<tbdinesh> how can it be an errata. its a MAY
azaroth: are their any other thoughts?
RESOLUTION: Unless the i18n group advise otherwise, the WG will
not remove textDirection and processingLanguage from the model
azaroth: the other one ivan proposed seem to say if we could
come up with something better we would
ivan: yeah. we've mostly already said this via other comments
azaroth: correct, we've said essentially "if anyone has other
commentary, we're happy to hear it."
<ShaneM> as long as the change is non-normative!
ivan: right, as long as we've stated that we're here and
accepting input
<azaroth> PROPOSED RESOLUTION: WG is happy to improve the text
of the textdirection, processinglanguage descriptions with
clear input as to what those changes should be
+1
<ivan> +1
<tbdinesh> +1
<TimCole> +1
<azaroth> (and indeed, any other text in any of the documents!)
<azaroth> +1
<bjdmeest> +1
<takeshi> +1
<ShaneM> +1
<PaoloCiccarese> +1
RESOLUTION: WG is happy to improve the text of the
textdirection, processinglanguage descriptions with clear input
as to what those changes should be
takeshi: I noticed that processingLanguage does not state what
values should be used
azaroth: yes. you are 100% correct.
takeshi: to make things administratively right, let's get that
added as a GitHub issue
... so it has a place, and the editors can handle it
... because we need to have documentation for all our changes
<azaroth> PROPOSED RESOLUTION: Clarify that the value of
processingLanguage SHOULD be bcp47, as per language.
<TimCole> +1
<azaroth> +1
<bjdmeest> +1
<takeshi> +1
<tbdinesh> +1
<PaoloCiccarese> +1
+1
azaroth: do people think we should invite the I18N folks to the
meeting next week?
ivan: probably, we should show public support--again--to say we
support their input
RESOLUTION: Clarify that the value of processingLanguage SHOULD
be bcp47, as per language.
<azaroth> trackbot, pointer
<trackbot> Sorry, azaroth, I don't understand 'trackbot,
pointer'. Please refer to
<[14]http://www.w3.org/2005/06/tracker/irc> for help.
[14] http://www.w3.org/2005/06/tracker/irc
azaroth: I will make an issue that says that our content is
based on the input of the I18N group
Testing
azaroth: one key piece to discuss is testing the value of
properties even if the property is optional
... including format and language
... there is an ever increasing number of media types
... and there's on the order of 8k languages and sub features
on those
... that also in theory could be tested with a JSON Schema
... but that seems like massive overkill
... and seems impossible to maintain
... given the ongoing addition to both lists
... so perhaps we can test the shape of the strings
<ShaneM> ^[a-z][a-z][a-z]?
azaroth: using the list of top-level media types followed by a
slash followed by some other characters
... is probably sufficient for media type
TimCole: I agree that if the feature is optional, we won't try
to be perfectly rigorous, but we will try to warn if the shape
is wrong
... that seems better than not testing at all
... the perfect solution would need to use an outside services
... we can continue to test the MUST requirements more
rigorously
... the other issue that came up was that if testing the value
it's possible to add some more clarity to what the value should
be
<ShaneM> it means we need a separate assertion
TimCole: there were a couple of other things
... there are situations where we reference external
vocabularies
... two keys on Annotation:
... audience and accessibility
<azaroth>
[15]https://www.w3.org/TR/annotation-model/#intended-audience
[15] https://www.w3.org/TR/annotation-model/#intended-audience
<azaroth> (and following section)
TimCole: the audience one should be from the Schema.org
namespace
... these come from the Schema.org classes
<azaroth> ^schema:(.+)$ ?
TimCole: right. as azaroth says you can check that the value
starts with `schema`
ShaneM: a follow-up question. Does the spec hard code the
prefix?
TimCole: yes.
ShaneM: excellent
TimCole: k. that sounds easy and we don't need to look up the
actual classes
... and then the last question
... we do have a few situations where it "should be exactly 1
but may be 0 or more."
... it seems worth checking these
ShaneM: thinking about. it's not a fail regardless
azaroth: seems like a warning if there's 0 or more than 1
... and fine if there's only 1
ShaneM: we have syntax for this in our assertion structure
... the tests can still continue even if this check fails
... what we need to do is make sure the message that comes out
with the failure states that it's a suggested feature and not
an actual failure
TimCole: could you clarify the "succeed and continue"
situation?
ShaneM: "succeed and continue" is not the result, it's the
expected result?
... so if the thing worked, continue. which is what you'd
expect it to do
... I think we should just play with the combinations and see
what we get
TimCole: I'd like a message to come out in the results which is
a warning, but that the process does continue
... and its still marked as valid
ShaneM: unfortunately WPT has no method for outputting a
message when things are successful
TimCole: so passing the test is fine, but if you didn't pass
the test, then we could "succeed and continue"
... we'll try that see if that's what we need
ShaneM: right. that'd be the approach I'd suggest
TimCole: we also have definitional schemas and other schemas
that can be used as test scripts
... we should be able to try and run some test scripts next
week
... and we'll be working on section 4 and section 5
... the goal being to have all the schemas built next week
... and perhaps we could get help running the test scripts
... if I provide some draft test scripts
ShaneM: I'm happy to do that. the test dev environment is
actually up and running
<ShaneM> testdev.spec-ops.io:8000/tools/runner/index.html
ShaneM: and stays up to date with the repo
TimCole: k. we'll try that
... the tests could compare a series of assertions
... I'd like to put something together that puts all the
optionals together
ShaneM: I think that's fine. as long as there's an annotation
that matches those criteria
... there's just no way to do it with one huge schema, because
there's no way one annotation would exercise all those tests
TimCole: great. we're hoping to put stuff together with some of
these libraries
... perhaps in another language besides JS
<ShaneM> [16]https://www.npmjs.com/package/language-tags is a
JS package to validate language tags btw
[16] https://www.npmjs.com/package/language-tags
azaroth: happy to help with Python for one
TimCole: if nothing else is needed here, let's move on to
protocol testing
<TimCole> scribenick: TimCole
Protocol Testing
bigbluehat: protocol multiple headers was a bit of a red
herring
<ShaneM> [17]https://www.npmjs.com/package/media-type JS
library
[17] https://www.npmjs.com/package/media-type
bigbluehat: have a stack of PR to bring protocol more in line
with LDP
ivan: are they all editorial?
bigbluehat: maybe not, e.g., prefer headers...
... include parameter in 2 headers, the latter should override
... have rewritten the spec language to make clear how multiple
headers work together
ivan: a little lost in details
<bigbluehat>
[18]https://rawgit.com/w3c/web-annotation/fix-333-multiple-http
-headers/protocol/wd/index.html#h-container-representation-pref
erences
[18] https://rawgit.com/w3c/web-annotation/fix-333-multiple-http-headers/protocol/wd/index.html#h-container-representation-preferences
bigbluehat: so this is the section that I've proposed be
revised
... includes how LDP specifies the link headers should look
ivan: this seems making more precise, not a technical change?
<tbdinesh> yes there is
azaroth: the CR doesn't mention multiple headers, so perhaps
this is a clarification
<ShaneM> [19]https://www.w3.org/TR/annotation-protocol/
[19] https://www.w3.org/TR/annotation-protocol/
bigbluehat: we did add an 'example 4', was not in CR
... so this is editorial
ivan: any change (even editorial) has to be fully documented
and determined to be editorial
azaroth: for the PR for this protocol issue, can we go ahead
and merge after update section is updated
bigbluehat: Note, the PR includes a few other clarifications
... will add something to the changes section and then azaroth
can merge
azaroth: how close to protocol testing implementation?
bigbluehat: updated to do include headers properly
... researching how to get into WPT
<bigbluehat>
[20]https://github.com/Spec-Ops/web-platform-tests/pull/3
[20] https://github.com/Spec-Ops/web-platform-tests/pull/3
ShaneM: at point where we want to request merge into WPT (once
mergeable)
bigbluehat: yes. and once merged should be fully compliant
annotation server
<tbdinesh> is there an annotations "dump" somewhere that can be
used for protocol testing?
azaroth: anything further on protocol?
<Zakim> ShaneM, you wanted to ask a question about model
testing (before we adjourn)
ShaneM: found js tests for media types and languages
... ajv supports this
... does not rely on external services
... ajv implementation does not rely on external services
azaroth: would tie implementation to ajv libraries
... would not be able to use in python
... if possible to have a branch?
TimCole: wait and do later, but not slow down progress on
implementation testing
AOB?
Summary of Action Items
Summary of Resolutions
1. [21]Minutes of the previous call are approved:
https://www.w3.org/2016/07/29-annotation-minutes.html
2. [22]Unless the i18n group advise otherwise, the WG will not
remove textDirection and processingLanguage from the model
3. [23]WG is happy to improve the text of the textdirection,
processinglanguage descriptions with clear input as to what
those changes should be
4. [24]Clarify that the value of processingLanguage SHOULD be
bcp47, as per language.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [25]scribe.perl version
1.144 ([26]CVS log)
$Date: 2016/08/05 16:08:41 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 5 August 2016 16:09:46 UTC