Re: Distributed Extensibility

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?

> Note: I don't care for the use of pejorative terms like walled  
> gardens here.  I will readily concede that the term is accurate,  
> but it is a distraction.

Let's call them specific non-Web-scale systems then. The intent of my  
question is was to understand what you were designing you proposal for.

Is it for
  * Cases where the producer targets a specific consumer system and  
known what its capabilities are and the specifiers of the consuming  
system know that they can communicate specific requirements to the  
producer and they use Web specs as the foundation of their private  
stuff?
  * Cases where the producer puts stuff out there on the Web where  
various parties and pieces of software (including browsers) consume  
it in ways that don't involve a specific relationship with the producer?
  * Both?

> While we should encourage extensions,

This is not a technical objection to your proposal but I don't think  
it is clear that *encouraging* extensions is a good idea in the Web- 
scale case. We should encourage people to use well-known--not home- 
grown--markup vocabularies is cases that don't involve a private  
bilateral agreement.

> Conformance checkers that not only validate HTML structure, but  
> also validate that a/@href attributes are URIs (despite being  
> defined in a separate document) and that fb:default elements have  
> fb:switch elements as their parents (again, despite being defined  
> in a separate document).

On the other hand, it is most likely a mistake to serve Facebook  
templating language to a browser. Therefore, a conformance checker  
that is meant for checking Web content should probably flag leaking  
Facebook templating language as an error but a tool (or a mode of a  
tool) advertised for Facebook development should do the kind of  
Facebook checks you mention.

> As to MathML, we still need to decide whether or not to grandfather  
> in that vocabulary.

I haven't seen any explanation why grandfathering it would be better  
than establishing a namespace scope at <math>. Wouldn't  
grandfathering cause a whole lot of confusion and trouble if MathML  
evolves?

> 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?

>>> Implications
>>> ------------
>>  * As an unintended consequence an extension mechanism like this  
>> could make it possible to declare the HTML namespace with a prefix  
>> and hack different core element treatment in legacy UAs and  
>> extension mechanism-aware UAs. (This can be a good thing or a bad  
>> thing.)
>
> Let's simply declare that to be an error and be done with it.  I'm  
> also going to update my page with this one.

The potential good thing part would be able to hack structured inline  
content into <p> in text/html.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Saturday, 4 August 2007 10:30:09 UTC