RE: Marking issues resolved

Thanks for looking into that Gregg. 

> In the past, the way we've marked that issues in the specifications
> are resolved, is by adding the "resolved" class to the issue. For
> example, in the 20120930 version of json-ld-syntax/index.html, we had
> issues 114 and 133 marked resolved:
> 
> <p class="issue resolved" data-number="114">This section is an attempt
> to formalize a normative grammar for JSON-LD.</p>
> 
> These were apparently dropped sometime after that, which is somewhat
> unfortunate, but hardly a problem.
> 
> We also had the following CSS:
> 
> .issue.resolved { display: none; }

Oh.. that's what you meant. I thought you wanted to render them in a
different way. I don't think it makes much sense to keep them in the
document if they are hidden - at least not if all 100+ other issues are not
included as well (most of them have never been).


> I also see that we stopped using issue numbers to actually reference
> the GitHub issues, which we should do. Ideally, we would put back
> removed issues and reference the appropriate GitHub issue. For

We stopped doing so because Sandro asked us to create a document which
summarizes the features at risk. He proposed to use RDF WG wiki to do so..
and that's what I did. I couldn't find a way to define an anchor tag in the
wiki and so I just used numbers without transforming them to links. That's
also why there's the 'For the current status see features "at risk" in
JSON-LD 1.0' statement in every issue maker.


> example, the previously mentioned issue would actually reference
> <https://github.com/json-ld/json-ld.org/issues/114>. Issues currently
> in the json-ld spec are just numbered 1-4, and result in URLs which
> don't reference the appropriate issue.

They are not rendered as URLs, so not a problem I would say. Having
something like "Feature at risk 114" would look very strange IMO because it
gives that impression that there are 113 other Features at risk.


> ReSpec doesn't yet have specific support for noting these as issues
> (open or resolved) in RDFa. Shane did this manually in the RDFa Core
> 1.1 spec, as follows using bibo [1]:
> 
> [...]
> 
> Now that ReSpec has better issue support, I think we can update ReSpec
> to generate better markup. However, I think that bibo:affirmedBy is
> being misused, as it relates to legal decisions. For that matter, a
> bibo:Issue is not like a GitHub issue, but relates to an issued
> document: "something that is printed or published and distributed,
> esp. a given number of a periodical".
> 
> The closest to what we want is probably [2]. Looking at a current
> atrisk definition, this might be rendered described as follows:
> 
> [...]
> 
> Note that data-number is changed from the current "1" to "223", which
> matches the issue on GitHub. This might generate the following markup:

I'm wondering whether we shouldn't keep it simple and just delete them. We
resolved them and so there's no reason they are still in the document.
Kingsley converted all issues to RDF already so we have all the data.


So, can we just remove the following issue markers?
 - @base keyword
 - Converting list of lists to JSON-LD
 - Use of method overloading to make the options parameter optional
 - Default value of base member in JsonLdOptions

That would leave us with two features at risk:
 - Reverse properties
 - Allow blank nodes to be used as graph name or property



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 7 May 2013 21:23:42 UTC