Getting these in in time for the F2F.
No Comments on present content.
might be prevented in the context of distributed extensibility using techniques such as modularized namespaces? Compare and contrast such distributed extensions with centralized vocabularies.
Might be worthwhile addressing how a new producer should behave when the user requests content that is explicitly for an old consumer. It would also be worthwhile to distinguish between evolution strategies where authors are insulated from knowing the distinction between old vs new (implicit creation?) vs those scenarios where authors are explicitly aware of the distinction, and therefore are given control on whether they produce content with a new producer that specifically avoids all new features.
This section could do with an example.
Minor nit: there is a repeated period --- search for "..". The example used --- URI for a resource that is http or https --- raises the complicated issue of identity that might perhaps complicate the present issue where we dont need such complexity. The issue of URI for resource identity --- and the unfortunate consequences that result in this context from the URI being tied to a protocol is unfortunate, and in my opinion a profound architectural issue; I'd just like to keep it out of this document for now.
Top-level generic comment: this section reads well. However, we might be giving ourselves too much credit with respect to pointing at the addition of the img tag to HTML1 as a shining example of extensibility. Looking at it in the cold light of the mess that is the Web today, I postulate that extensibility in 1991 was easy because there wasn't much content to extend. To see this, let's ask ourselves what would happen if one tried to view the Web through a lens today that cannot handle the img tag. I assert that it's far more complex than it just works without the images --- this happens because of the large amount of significant content and behavior that has been stuck away behind the img tag. In 1992, if you browsed the Web with a user-agent that didn't understand the img tag, the losage would have been minimal; not so in 2008.
Another point to remember about the img tag; it looks simple when described as an empty element whose appearance it dictated by one of two attributes --- an src attribute for the image source, and an alt attribute for fallback text. Yet, more than 14 years after its invention, introduction of the data: scheme in the value of the src attribute causes browsers that dont understand that idiom to display a black hole in place of the image, i.e., there is more to the img tag than meets the eye!
Response to EdNote: I believe the ability to do explicit versioning goes hand-in-hand with extensibility.
The term text glosses over whether the unknowns appear at the tokenization phase or during the post-tokenization phase. I believe this is a valuable distinction to expound on --- especially from the view of designing parsers. In paragraph that starts with
Another way of looking at this combination is that there are two languages. The browser renderer understands HTML which involves ignoring unknown elements or attributes. By our language definitions, the renderer'sthe jump to HTML browsers is both surprizing and jarring. I'd suggest refactoring or rearranging this and the preceding paragraphs so that we move sequentially through arguments that cover tokenization, serialization and DOM structures, with examples from XML tokenization, HTTP header handling and HTML DOM going hand-in-hand with each.
Not sure if I believe the argument about the script element with respect to must ignore children --- from memory -- and this still shows in the bizarre tricks authors trying to validate use to hide scripts --- the issue was a mixture of:
In the context of MIME providing fallback support, it is interesting to observe the resulting chaos that gets created in the following usage scenarios:
Consequence: the two parts quickly fall out of sync, and one is left with a mush that makes TAG-Soup look appetizing.
>From the text, it sounds like we're equating minor versions in a manner similar to how we want to handle backward/forward compatibility for unversioned languages. It might be worth pointing this out explicitly if that is indeed what we're saying --- AKA, reduce to previously unsolved problem. With respect to supporting additional functionality it might be worth noting that once the author has tested for the availability of a given functionality, she is back in the situation of having to provide fallback content for cases where the test returns false.
Date: 2008/05/19 10:39:10