Re: ISSUE-41/ACTION-97 decentralized-extensibility

Tony Ross wrote:
> On Sunday, October 18, 2009 3:12 AM, James Graham wrote:
>> Quoting Tony Ross <tross@microsoft.com>:
>> 
>>> I feel HTML 5 already provides an elegant means of simplifying 
>>> popular extensions based on XML Namespaces with its handling of
>>> SVG and MathML. Per your example, HTML 5 itself will enable
>>> authors to use vector graphics without a knowledge of namespaces
>>> because the SVG namespace will be assumed when an <svg> element
>>> is encountered. Other extensions could initially require the use
>>> of namespaces in markup, but then be integrated into a future
>>> version of HTML in the same manner should they become popular
>>> enough. Consequently an author would only be "forced" to use
>>> namespaces in markup for extensions that had not yet become
>>> popular enough to be integrated into HTML.
>> Experience with SVG and MathML suggests that this kind of post-hoc 
>> denamespacification becomes significantly more problematic when the
>> tag names of the imported vocabulary clash with the existing HTML
>> tag names. Therefore if one can imagine ones vocabulary being used
>> in HTML without explicit namespacing in the future, one must design
>> it with unique tag names from the start. Given this, the supposed
>> advantages of namespaces to vocabulary designers don't apply in
>> this situation.
> 
> From a technical standpoint I don't see this as a major problem. So
> long as your vocabulary has a root-type element that doesn't clash,
> the identity of the remaining descendant elements can be determined
> without explicit namespacing, even if they utilize names that clash
> with HTML.

This doesn't always work so simply. For example HTML5 has to have a list 
of elements that break out of foreign content modes to avoid breaking 
existing pages that, for some reason best known to their author, mix 
random fragments of SVG and MathML with HTML markup and expect it to 
have no effect. Where names clash (e.g. <font> this handling becomes 
even more complex and fragile).

Received on Wednesday, 21 October 2009 08:51:50 UTC