Re: Distributed Extensibility

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 Saturday, 4 August 2007 15:11:26 UTC