Re: Distributed Extensibility

Henri Sivonen wrote:
> 
> On Aug 3, 2007, at 19:59, Sam Ruby wrote:
> 
>> Henri Sivonen wrote:
>>> On Aug 2, 2007, at 18:16, Sam Ruby wrote:
>>>> Since the workgroup demands use cases for any proposed new feature, 
>>>> I will provide one up front: this feature’s use case is to enable 
>>>> features without use cases.
>>> ...
>>>> FBML isn’t intended to be directly processed by browsers, but that 
>>>> shouldn’t preclude it from being processed by other HTML5 tools, 
>>>> everything from sanitizers to conformance checkers to pretty 
>>>> printers, to search engines.
>>> Is it the assumption that HTML5 so extended would be served on the 
>>> public network in ways that would routinely expose the extension 
>>> markup to browsers? If the extensions are intended to be processed by 
>>> non-browser tools in the context of a walled garden such as Facebook, 
>>> wouldn't XHTML5 plus namespaced extensions work?
>>
>> Perhaps, for the six of us or so that seem capable of consistently 
>> producing well formed XML.
> 
> OK. So do I understand correctly that the proposal is essentially to 
> extend the text/html serialization to a more general-purpose (even if 
> not fully general) alternative infoset serialization for private systems 
> where the people working with the private system cannot be trusted to 
> use XML?

Wow.  What a loaded question.

First, I don't see how fb:mobile is any more or any less "private" than 
canvas.

Second, I don't even know where to begin with "cannot be trusted to use 
XML".  Let me pose a question.  If Apple had decided that the canvas tag 
could only be used inside of XHTML pages, what affect would that have 
had on the adoption rate of that feature?

>> Time for a concrete example:
>>
>> http://intertwingly.net/svg/410.svg
>>
>> If I don't use CDATA, the "410" shows up in IE.  If I do use CDATA, 
>> nothing shows up in IE.
>>
>> We need a way to say "if you can't handle this extension, don't show 
>> anything (or perhaps, show a fallback defined separately)".
>>
>> Now, if we allow this use of CDATA, we need it to actually show up as 
>> a text node in the DOM as opposed to a comment node when used in 
>> precisely this circumstance.
> 
> So the tokenizer handling of CDATA syntax would change depending on 
> whether the application layer knows about the kind of element that is 
> the current node on the tree builder layer at the particular moment?

"application layer"?  No.  One can determine such factors as "does the 
name of the target parent element contain a colon" without needing to 
reference the hosting application.

- Sam Ruby

Received on Saturday, 4 August 2007 11:52:14 UTC