Meeting minutes
Announcements and Introductions
[none]
YAML-LD check-in
anatoly-scherbakov: several comments on PRs, thanks to the commenters
… some PRs merged
<anatoly-scherbakov> w3c/
<gb> Pull Request 184 [#36]: Add informative JSON literals section with YAML examples after Scalar Value Types (by anatoly-scherbakov)
anatoly-scherbakov: this PR needs reviews
… one question: as an informal rule that with 2 approvals, I would go and merge the PR
… do we have more formal rules?
ivan: each WG decides on its own
… my practice in other WGs is to give a minimum time (usually a week), that plus a number of approval is enough IMO
… that depends on the PRS (editorial or substantive)
… labelling PRs is also a good idea
… if a PR is clearly labelled as editorial, you could have more power
bigbluehat: that matches what we have discussed before
… editorial PRs are "polishing the apple"
… if something is controversial, it should get call time
<TallTed> +1 minimum PR life of a few working days, preferably a week, before merge
<TallTed> +1 wait for two or more approvals, or no objection during a call with quorum
bigbluehat: we have a 'needs-discussion' label for marking such PRs
… I think a week cooldown for a PR is useful
pchampin: +1 to what was said
bigbluehat: is there any PR that you want to draw attention to?
anatoly-scherbakov: not necessarily
… PR yaml-ld#184 is a clarification about idiomatic YAML representation of JSON literals
bigbluehat: this is the kind of PR that benefits for more reviews
ivan: I have no problem with this, but is it a general YAML thing, or something specific to what we do?
anatoly-scherbakov: this is related to the use of the `"@type": "@json"`
<ivan> +1 to bigbluehat
bigbluehat: I remember an earlier discussion where it was suggested that `@raw` would have been a better name
<niklasl> Makes sense to me to point it out; it needs to be the same subset as for YAML-LD in general.
pchampin: not sure I caught all that
… but the second example is indeed not JSON
<niklasl> (And agreed, it's not json (the serialization) internally in JSON-LD either, it's the internal representation".)
pchampin: I agree the `@json` name is misleading
… so, I think having both examples is good
… but the current second example should be updated to be explicitly JSON to help clarify
ivan: so what's the problem exactly?
pchampin: I want to be sure that any/all of these will be parsed by the YAML parser
<niklasl> +1 to pchampin
anatoly-scherbakov: we can keep only the example that is YAML idiomatic
pchampin: and that the `@value` is still properly parsed via YAML
bigbluehat: I also find the "WebContent" thing confusing
<anatoly-scherbakov> +1
pchampin: +1 or simply "schema.org description (of a WebContent)"
CBOR-LD Issues
<TallTed> https://
Pull Request 61 Update top-level encoding/decoding algorithms to support uncompressed use cases. (by wes-smith)
wes-smith: we started covering this PR last week
… it is simple, the algorithm assumes semantic compression, while the text says you don't need to use it
… the PR adds a top-level condition in the algorithm, testing if semantic compression is present, bypassing that part of it is not
bigbluehat: does it relate to the mailing list conversation at https://
wes-smith: it is related, but this PR is not a change in a spec in reaction to the conversation
… the spec was never intended to impose semantic compression
… the algorithms were named "compression" and "decompression".
… People not interested in "compression" per se were fairly confused.
ivan: what is the use of CBOR-LD without semantic compression?
wes-smith: let's table this question until the next PR
bigbluehat: no objection to merge this?
[none raised]
Pull Request 63 Add discussion of processing model and semantic compression. (by wes-smith)
wes-smith: this is a larger PR, related to ivan's question
… rewording of the text clarifying the goals of the technology, what you can and can't do with CBOR-LD
… [comments the summary of the PR]
… please read the intro of "Basic Concept"; it describes 3 types of compression
… semantic compression is based on concepts
… typed value compression with codec is based on understanding of the datatypes
… typed value compression with registry is based on static dictionaries
… each of them is optional
… there is a "default processing mode" (use semantic compression + codecs described in the scep), but registry entries can override that
pchampin: what you said about registry entries and what they can specify--especially processing models
… is there a way for an implementation to discover everything it needs to do from the registry?
… or do I need to hard code all this in advance?
wes-smith: it's an open question
… can we make a machine readable registry such that code could pull down the registry and do the right things
… there's some f that in place now and issues for exploring it further
… there are more challenges, though, if we go that route fully, like expressing logic
… and how we express that logic would be an open question
… it would essentially be a template logic language thing that any implementer could use
… and some of those could be very hard
… and we need to decide if the "juice is worth the squeeze"
ivan: I'm a bit worried, beyond the technical details, that we are going in a direction with work work than we can handle
… we need to setup mechanisms for managing the registry
… we need a test suite that handles things that are not LD
… is there a way to separate the non-LD things, and make them optional?
wes-smith: that's a good point; we need to think practically on how we want to cut up the work
… at least the basics of what we are discussing are not huge lifts
… opening the doors to a fully machine-readable registry is making things difficult
… we could say in the spec that users can do whatever they want in the registry
ivan: absolutely; have the concepts clearly put in the document is really good
… whenever we touch on territory were non-LD applications can do this and this, we should state "but we do not define it"
<wes-smith> +1
ivan: not even defer to future versions
bigbluehat: I'm wondering how to test these things if they are not machine readable
wes-smith: you take a JSON-LD document and encode it using a dictionary
… you roundtrip it without collusion between the encoder and the decoder
… let's examine the registry entry 31000000
https://
pchampin: just to be clear. I'm not insisting the registry be fully machine readable, but I agree with ivan that the complexity is likely more that we can handle
… but it would be nice to have some registry entries that point to human readable specifications
… with regard to testing, it would be good to see how that is/will be done
… we could shy away from that and say each registry entry is not ours to test
wes-smith: +1 to what you said
wes-smith: +1 to what you said
… we are discussing which part of the registry can or can't be made machine readable
… managing the registry does not imply that we have to test each entry
… a registry entry can even mandate a table that is not included in the entry
ivan: thinking out loud; a registry entry like this one could have a link to a specification
… we could test only the "transparent" registry entries, and explicitly not test the "opaque" ones that point to a specification
wes-smith: I mostly agree; we sort of already have what you are describing
… entry 0 is default processing mode without semantic compression
… entry 1 is default processing mode with semantic compression
… they are implicitly pointing to our specification
bigbluehat: how do we distinguish between the two? 0 and 1 look identical
wes-smith: yes, we need to refine the description (boolean flag for semantic compression, list of codecs)
dlehn: are the entries will eventually contain the codecs?
wes-smith: the codecs that we currently use are supposed to go into the spec and be part of the default processing mode
dlehn: some of them are very use-case specific; people may come up with others
wes-smith: we still want to provide a default list of codecs, and provide a way to add more in the registry entry
dlehn: maybe some implementations will not implement everything
bigbluehat: wes-smith could you draft something about codec expression for the next call?
wes-smith: that would be a usefulthing to do, but I can't promise to do that rapidly
… you can look at our code
bigbluehat: please send a link to the mailing list