- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 14 Oct 2013 13:13:12 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: RDF WG <public-rdf-wg@w3.org>, JSON-LD CG <public-linked-json@w3.org>
On 10/09/2013 12:39 AM, Manu Sporny wrote:
> On 10/08/2013 10:58 PM, Sandro Hawke wrote:
>> I guess our emails crossed.
> Yeah, sorry, didn't check my RDF WG folder before sending this email.
>
>> Are you only proceeding with 'json-ld' not 'json-ld-api'?
> Both documents would proceed at the same time.
>
>> Or if you mean both, then what's the plan re Promises?
> To make the API non-normative
That makes sense. Are the editors settled yet on what json-ld-api
should refer to as the spec for Promises?
Unfortunately, the 'Feature At Risk' warning in json-ld-api [1] didn't
anticipate changing the whole section from normative to
non-normative. Normally this is the kind of change that requires
another Last Call. The avoid that, we'll have to make a credible
argument for why this change wont invalidate anyone's review. I'm
trying to think about what would be most helpful there.... I don't
want to push Ralph on this until we're clear how we want to do it.
[1] http://www.w3.org/TR/2013/CR-json-ld-api-20130910/#at-risk-8
> and update the document when we can put in
> a normative reference... which will be months/years from now. In the
> mean time, we already have JavaScript implementations that use Promises.
Which execution environments provide Promises now? If it's two
prominent ones (eg chrome and firefox) and they both conform to some
spec, we could argue it's stable enough to use in a Rec (instead of
doing the non-normative thing above).
>>> 1. Make the JSON-LD data model and the reference to RDF Concepts
>>> non-normative, go to REC, and make the reference normative when
>>> RDF Concepts goes to REC. This seems like the best option.
>> You want to do two more publications and a second AC review 3 months
>> later just to make this tiny change?
> An AC review isn't required for a 2nd Edition of a spec, right?
> Especially for a tiny change such as this. We'll point it out in the
> SoTD, like we did for HTML5+RDFa 1.1. Something to this effect:
> RDF Concepts is currently in the Last Call phase and so references to it
> cannot be normative. This means that the JSON-LD data model and
> relationship to rdf sections are not normative. RDF Concepts 1.1, as it
> is employed by JSON-LD, is considered stable enough to be implementable
> in a production environment. Once the RDF Concepts 1.1 document goes to
> REC, all references to RDF Concepts 1.1, as well as the data model and
> relationship to RDF sections, will become normative.
>
> The AC reps will see that text when they vote to approve the document as
> a REC. When RDF 1.1 Concepts becomes a REC, we just go in and make those
> changes. No need for an AC review.
I see your logic, but we don't get to pick and chose, even with putting
people on notice like this. Any publication or re-publication of a W3C
Recommendation requires formal review by the AC.
Logically, yes, we should be able to at least update the references --
changing PRs to RECs -- without W3C AC approval, but the current process
doesn't distinguish different kinds of changes like that, so it doesn't
support such changes. And it turns out improving the process is
particularly difficult. If you want to help with that, well, I
understand the AB is working on it.
>>> 2. Delay JSON-LD proceeding to REC until RDF Concepts becomes a
>>> REC. This would be a terrible outcome.
>> What specific harm will be done by delaying json-ld by two months?
> Adoption will be delayed yet again.
Indeed. :-(
> It's also a distraction to the
> members of the JSON-LD group that would like to move on to other things
> like RDF Graph Normalization and JSON-LD Framing.
Yes. It's not a waste of time, since it can happen in parallel, but
it is a distraction.
> It'll put into
> question whether or not we should be updating the test suite or we
> should delay updating the test suite until the REC is done.
The test suite used for CR should be archived on w3.org, and by all
means fork it and be adding new non-normative tests after the fork.
> If we do
> update the test suite, do we need to go through another CR/LC?
The test suite is not part of the document, so no change to the test
suite affects document status.
> Many
> people in the group would just like to ship JSON-LD 1.0 and move on,
> delaying it by 2-3 months because RDF Concepts /might/ change (which it
> probably won't at this point) seem silly.
Yes, it does seem kind of silly.
To me it seems like a lot of coordination processes. It seems absurd
that I need wait for the building inspector to double checking the
wiring before patching up the walls, when the change was tiny and I can
see it's fine. And yet, I understand why that rule exists.
>
> At this point, it's really the W3C process that seems silly. We should
> be able to publish the document as a REC, note the changes that will
> happen in the 2nd Edition in 2-3 months, and be done with it without
> much AC fanfare. Is there any way we can do this?
Well, give or take the word 'fanfare' would could do that. That is, we
need to ask the AC before doing the 2nd Edition, but we don't have to
make a big deal of it.
On the other hand, my sense is that would look somewhat more silly (and
take more work) than just publishing everything together.
Yours in wishing this were much simpler, somehow,
-- Sandro
>
> -- manu
>
Received on Monday, 14 October 2013 17:13:21 UTC