Normative References to Moving Targets are Dangerous
Author(s) and publish date
- By:
-
-
Karl Dubost
-
- Published:
The work of W3C is sometimes a bit opaque. It is not obvious to people outside of the Working Group. You often only read the end result, a Working Draft, even sometimes the specification.
Yesterday in the WebApps (Web Applications) Working Groups, a discussion has started about a normative reference from XMLHttpRequest to HTML 5. XMLHttpRequest is the technology used in AJAX applications on the Web. XMLHttpRequest is more mature and in the final stages for going to last call and hopefully in a few months a W3C Recommendation. HTML 5 is still in high development and not stable at all. There is still work to do on it. Two options were proposed:
- Should the normative requirement in XMLHttpRequest be a reference to the specific prose in HTML 5?
- Should the normative requirement in XMLHttpRequest be included in the prose of XMLHttpRequest?
There is no formal Process requirement on this, because it is highly dependent on the type of the technology and its level of maturity. The W3C Process Document is here to help and be flexible to many use cases, and not be a hurdle. There is an internal W3C Technical Report publication processes. When a document is moving to Proposed Recommendation, it has to satisfy all exit criterias of Candidate Recommendation. In this document, we can read
Evidence that dependencies with other groups met (or not)
- Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations.
- Is there evidence that additional dependencies related to implementation have been satisfied?
What does it simply mean? Normative references to moving targets are dangerous.
Including the relevant bits of HTML5 would make XMLHttpRequest huge and put the issues HTML5 has in those areas in XMLHttpRequest.
The problem is slightly more subtle than the way you put it. The Window object as a concept is pretty widely understood. And the way it is used in XMLHttpRequest is not controversial in any way. However, defining the Window object without defining some of the other important bits about it, such as history, navigation, and browsing contexts, does not make a whole lot of sense. (And in fact those concepts apart from history are relevant to XMLHttpRequest.)
(The Window object is not the only reference, other parts include e.g. the definition of event handler attributes or serializing a Document object.)
Indeed. As I said, flexibility is an asset of W3C to find the right balance. Not always easy to do. Consensus and compromises. If a reference is given to a moving target, during the transition call, it has to be really documented. You basically have to make the case to say that you need to do it that way.
That said, it seems that this issue is advocating for technologies being modular with smaller specifications: easier to move forward, cheaper to write and implement, promote orthogonal design.
Anne, Do you think it would help if the relevant bits were in a smaller specification than the full HTML 5? Do you think it is possible at all?
(unrelated) For example, I have the strong belief that Canvas API could be put out of html 5 and have its own document and be already a recommendation in something like 3 to 6 months. It's well implemented. There are already plenty of test cases. It should be easy to move to Rec and be document that could be linked to for normative references by more than one technology.
Anne, What is your opinion about that?
Though smaller specifications might be easier to take forward and such, two small specifications of size X (Y) probably take more time than having one specification of size 2X (Z), but I don't really have data to back up that thought.
I have a slight preference for having some parts of HTML5 in separate specifications. In theory that's definitely possible as well, of course. However, until we have editor resources (Ian indicates his experience is that Z is simpler than Y) that will probably not happen.
Regarding the canvas element, sure. I do not feel too strongly about it. On the other hand, no it's still in a draft that is in flux we can easily add new features, such as the text API.