Re: Distributed Extensibility

Hi Sam,

Thanks for the replies (original message below). I guess that means I  
mostly understood your proposal, it just wasn't clear to me that I  
understood you correctly from the conversation so far.

Anyway, I think it is an exciting proposal that could have important  
implications. Especially to be able to use newly declared namespaces  
in a text/html serialization.

It sounds to me like we would need to do some extensive compatibility  
testing with existing browsers (although it sound like some of that  
has already been done). Especially if this could be made to work in  
IE, the other browsers might come along for the ride.

A artifact of this approach could also include introducing a new  
temporary HTML5 namespace for use especially in IE. That way new  
elements that did not have empty content models could be defined for  
HTML5. Through the use of an HTML5 namespace declaration, those  
elements would be treated as container elements rather than IEs  
treatment of them as two empty elements: ELEMENT and /ELEMENT. Other  
interaction would not be possible, but at least the contents of these  
elements could be styled with a canonical HTML5 style sheet. Of  
course, that's just one aspect of your proposal,but it's  something  
that could make HTML5 much more widely deployable (with some minor  
hacks) in the near-term. I guess the only other thing we'd need is an  
IE canvas plugin :-).

Take care,
Rob



Original Message
On Aug 4, 2007, at 10:11 AM, Sam Ruby wrote:

>
> Henri Sivonen wrote:
>> On Aug 4, 2007, at 14:52, Sam Ruby wrote:
>>> Wow.  What a loaded question.
>> I'm still not sure if the proposal is about non-browser consuming  
>> software in private systems only or also about browser consumers  
>> on the public Web.
>
> Also.
>
>>> First, I don't see how fb:mobile is any more or any less  
>>> "private" than canvas.
>> Canvas was private when it was only for Dashboard. Now that it  
>> works on the Web, it is no longer private. I think we are lucky  
>> that Apple didn't use a prefix or a separate namespace for canvas.  
>> Otherwise, we'd now be stuck with a prefix or a separate namespace  
>> for backwards compat.
>
> The flip side of that is that we are stuck with a broken "object".
>
>> As far as I can tell, fb:mobile today is specific to communicating  
>> with the Facebook engine. It isn't about communicating to whatever  
>> app happens to issue an HTTP GET. That seems private to me.
>
> While I still don't buy into the dichotomy between private end  
> public that you propose (is marquee "private"?  is marquee about  
> "browser consumers"?), we seem to agree that some things that were  
> originally designed for one context often find a productive future  
> in another.
>
>>> Second, I don't even know where to begin with "cannot be trusted  
>>> to use XML".
>> Those questions were not opposition to you proposal but attempts  
>> to elicit more information about what it is that it being proposed  
>> and why. I can guess that the premise behind the proposal may be  
>> that XML is too hard. (And I don't necessarily disagree.) But  
>> instead of making guesses and then continuing from my own guesses,  
>> I'm interested in what your premises behind the proposal are.
>
> You are asking these questions in the context of a mailing list.   
> This mailing list is predicated on the assumption that an alternate  
> syntax than XML is worth pursuing.
>
> In that context, I'm attempting to put forward the case that  
> distributed extensibility is a necessary feature.
>
>>> 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?
>> Of course that would have had an adverse effect on adoption.
>> I have a feeling that you see my questions as opposition that  
>> needs to be answered with a counter-question. I'm trying to find  
>> out what the premises of your proposal are. I still don't know  
>> what the premises are.
>
> This post has no questions.
>
>>>> 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.
>> Sorry about being thick, but I'm still not sure what changes you  
>> are suggesting to CDATA tokenization.
>
> Given this input:
>
>   <p><![CDATA[x]]></p>
>
> HTML5 current interprets that exactly the same as:
>
>   <p><!--[CDATA[x]]--></p>
>
> I'm proposing that given this input:
>
>   <o:p><![CDATA[x]]></o:p>
>
> HTML5 would treat that as:
>
>   <o:p>x/o:p>
>
> - Sam Ruby
>

Received on Sunday, 5 August 2007 00:15:54 UTC