I checked the spec, and the object in question is still undefined, and not cleanly mapped to a definition. 

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The references are appropriate.

(In reply to comment #2)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The references are appropriate.
> 

Since the references to SharedWorkerGlobalScope occur only in the section related to browsers (currently Section 5), I'm tying this bug to the existing issue related to the removal of Section 5:

http://www.w3.org/html/wg/tracker/issues/94

Reopening for fresh consideration. It seems to me that it would be easy to rewrite the relevant sections to avoid mention of SharedWorkerGlobalScope, by putting some of the relevant requirements in the Web Workers spec.

Instead of this: "A cache host is a Document or a SharedWorkerGlobalScope object. A cache host can be associated with an application cache. [WEBWORKERS]"

You could say "A cache host is the object that maintains an association to an ApplicationCache. Document objects are cache hosts. Other specifications may allow other objects to act as cache hosts."

Then Web Workers could say: "For purposes of the HTML5 Application Cache, a SharedWorkerGlobalScope object is a cache host. [HTML5]"


This could just go right in Web Workers: "A SharedWorkerGlobalScope can be associated with an application cache when it is created. [WEBWORKERS]"

This could also go right in Web Workers: "The applicationCache attribute on SharedWorkerGlobalScope objects must return the ApplicationCache object associated with the worker. [WEBWORKERS]"

These are the only 3 normative references to WEBWORKERS in HTML5, as far as I can tell. Fixing these up in the way I suggested would make HTML5 no longer depend on Web Workers, thus removing a reference cycle. It seems to me like this is a significant editorial improvement. It would also be one less thing to deal with through the issue process.

It would be trivial to remove the references, my point is that the references are the best way to get interoperable implementations. Why would we remove them? It would be like removing all references to SVG and saying that the SVG spec should define deltas on the HTML spec.

(In reply to comment #5)
> It would be trivial to remove the references, my point is that the references
> are the best way to get interoperable implementations. Why would we remove
> them? It would be like removing all references to SVG and saying that the SVG
> spec should define deltas on the HTML spec.
> 

I think my suggestion to define the relevant requirements would be just as effective at leading to interoperable implementations. If someone is implementing both Workers and AppCache, they need to read both specs. And one-way references tend to be easier to understand (in this implementor's experience) than circular references, when dealing with the interactions between multiple specs. In fact, different details of the integration points are in each of the two specs, which I think is overall more confusing.

SVG is not analogous; there aren't references from SVG to HTML, so we don't have a reference cycle. It would actually be worse if the specs mutually cross-referenced each other.

Anyway, this is just my opinion. If you don't buy it, feel free to WONTFIX again.

There only aren't references from SVG to HTML because SVG doesn't define how it works with HTML. That's a bug, not a feature. :-)

However, if you as an implementor finds it more useful for the appcache stuff to be split across two specs instead of the workers stuff, I'm happy to change that.

AppCache is already split across two specs. There are appcache requirements in the Web Workers spec. My suggestion is to let appcache stay split across two specs, but have workers not be split.

Yeah, I guess that's reasonable. Will do.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: actually ended up adding a reference
Rationale: 

I tried to do this, but I really couldn't find a way to do it that:

(a) didn't introduce tautologies (like "A cache host is an object that hosts a cache" or something equally inane).

(b) didn't say anything technically wrong (like the proposed "A cache host is the object that maintains an association to an ApplicationCache"  it's no the case that all the objects that maintain an association to an ApplicationCache are cache hosts).

(c) didn't make the text make no sense in complete.html (e.g. talking about "other specifications" to mean another section in complete.html).

(d) didn't introduce gratuitous differences between WHATWG and W3C versions.

Web Workers and HTML5 really are just one spec, they're just split for W3C process reasons. This becomes very visible when trying to make the relationship one-way only like this.

While doing all this I found another place that referenced Web Workers from HTML5, so I added another reference.

If anyone has any suggestion for how to do this, please feel free to suggest what the text should be. I do see the argument that suggests that all the worker-related appcache stuff should be in the workers section and the appcache section should only talk about Documents, but I just can't really make it work that well in practice.

(In reply to comment #10)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: actually ended up adding a reference
> Rationale: 
> 
> I tried to do this, but I really couldn't find a way to do it that:
> 
> (a) didn't introduce tautologies (like "A cache host is an object that hosts a
> cache" or something equally inane).
> 
> (b) didn't say anything technically wrong (like the proposed "A cache host is
> the object that maintains an association to an ApplicationCache"  it's no the
> case that all the objects that maintain an association to an ApplicationCache
> are cache hosts).
> 
> (c) didn't make the text make no sense in complete.html (e.g. talking about
> "other specifications" to mean another section in complete.html).
> 
> (d) didn't introduce gratuitous differences between WHATWG and W3C versions.
> 
> Web Workers and HTML5 really are just one spec, they're just split for W3C
> process reasons. This becomes very visible when trying to make the relationship
> one-way only like this.
> 
> While doing all this I found another place that referenced Web Workers from
> HTML5, so I added another reference.
> 
> If anyone has any suggestion for how to do this, please feel free to suggest
> what the text should be. I do see the argument that suggests that all the
> worker-related appcache stuff should be in the workers section and the appcache
> section should only talk about Documents, but I just can't really make it work
> that well in practice.
> 

I wasn't asking that the references to SharedWorkerGlobalScope be removed. What I was asking for was to provide a link to where the item is defined, which you did, but also to provide enough of a description/definition to go with the link, so that people understand what this thing is.

A link to another specification is only useful if people understand why this link is given, and what they can expect to find at the other end. 

I have other things going on at the moment, but will attempt to provide suggested text, when I post some other change proposals. In the meantime, I'll just leave this bug in its current state. I don't think it needs to be upscaled to an issue, not until I take a shot at providing alternative text. WHen I do provide suggested text, I'll re-open this bug. 

If the alternative text is rejected then yeah, we'll need to upscale this bug at the time.

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.

The resolution was not satisfactory.

It looks to me like this bug was already escalated to the tracker as ISSUE-94, and is keyworded TrackerISsue. As such, VERIFIED is the correct state for this bug. My apologies for the slightly misleading comment. Because the bug is tagged already TrackerIssue, it won't get tagged NoReply and will not be considered finished until the tracker issue is closed.

(Resetting state back to VERIFIED WONTFIX.)

No, this is not related to Issue 94. 

Issue 94 may have an indirect impact on this bug, but there is no definitive link between the two. There is no issue for this item, and the re-open state is a legitimate one.

(In reply to comment #15)
> No, this is not related to Issue 94. 
> 
> Issue 94 may have an indirect impact on this bug, but there is no definitive
> link between the two. There is no issue for this item, and the re-open state is
> a legitimate one.

Earlier:

> (In reply to comment #2)
> Since the references to SharedWorkerGlobalScope occur only in the section
> related to browsers (currently Section 5), I'm tying this bug to the existing
> issue related to the removal of Section 5:
> 
> http://www.w3.org/html/wg/tracker/issues/94

You're also the one who tagged this bug TrackerIssue.

Removing TrackerIssue keyword since apparently you no longer think this is covered by issue 94.

(In reply to comment #16)
> (In reply to comment #15)
> > No, this is not related to Issue 94. 
> > 
> > Issue 94 may have an indirect impact on this bug, but there is no definitive
> > link between the two. There is no issue for this item, and the re-open state is
> > a legitimate one.
> 
> Earlier:
> 
> > (In reply to comment #2)
> > Since the references to SharedWorkerGlobalScope occur only in the section
> > related to browsers (currently Section 5), I'm tying this bug to the existing
> > issue related to the removal of Section 5:
> > 
> > http://www.w3.org/html/wg/tracker/issues/94
> 
> You're also the one who tagged this bug TrackerIssue.
> 
> Removing TrackerIssue keyword since apparently you no longer think this is
> covered by issue 94.
> 


And you're the one that re-opened the bug after I had planned on including it with Issue 94--triggering Ian into making edits to the document in an attempt to resolve your concerns, though ultimately he rejected your requests...kind of. 

So, yes, we'll leave it reopened and not tied to an IssueTracker, but let's not ignore all the history when doing so.

Delaying resolution pending availability of text mentioned in comment 11.

Shelley and Ian, would it be acceptable to both of you to put this bug in RESOLVED NEEDSINFO until the requested text from Comment 11 is available?

Fine by me.

You can close it. 

Marking RESOLVED NEEDSINFO per comments above and offline request.