Re: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Mon, 4 Aug 2008, Sam Ruby wrote:
> 
> The most I have ever argued for is not to take namespace prefixes off 
> the table prematurely.

When would you say it would become appropriate to take namespace prefixes 
off the table, then?

I do not believe anything was prematurely taken off the table, we did in 
depth analyses before deciding against such mechanisms. Eventually we have 
to make some decision. That decision presumably has to be based on data. 
As far as I know we have all the data we're going to get. Is there data 
that I haven't considered which would argue for not yet taking prefixes 
off the table?


> As to your main point: no question that a single, isolated div or span 
> is usable.  However, issue 41 is about enabling third parties to create 
> their own languages.  SVG and MathML were given as examples.  I realize 
> that MathML has subsequently been accepted (provisionally) into HTML5, 
> but consider what it would take to represent the following page into 
> HTML5 had that not been done:
> 
> http://golem.ph.utexas.edu/~distler/blog/archives/001758.html
> 
> If you can show a usable syntax for the above page given the notation 
> you suggested, then my appologies.

You are asking for a way for a third party to develop a syntax for 
embedding highly-structured mathematical data into a text/html document 
without approaching the HTML standards community, presumably in a manner 
that would not be supported by user agents?

Just so that I understand the request, how would one obtain interoperable 
renderings of such a language? Would one use scripting, CSS and XBL?

If so, then the class="" attribute mixed with existing HTML semantic 
markup seems like a perfectly adequate solution already, as in:

   <p>We'll work in Euclidean signature. Let <span 
   class="math"><var>M</var></span> be a Riemannian 4-manifold, and <span 
   class="math"><var>V</var><span 
   class="mo">&#x2192;</span><var>M</var></span> a complex vector bundle 
   with unitary connection.</p> <div class="math"><var>D</var><span 
   class="mo">:</span><var>&#x393;</var><span class="mo" 
   data-stretchy="false">(</span><span class="msup"><var>S</var> <sup 
   class="mo">+</sup></span><span 
   class="mo">&#x2297;</span><var>V</var><span class="mo" 
   data-stretchy="false">)</span><span 
   class="mo">&#x2192;</span><var>&#x393;</var><span class="mo" 
   data-stretchy="false">(</span><span class="msup"><var>S</var> <sup 
   class="mo">&#x2212;</sup></span><span 
   class="mo">&#x2297;</span><var>V</var><span class="mo" 
   data-stretchy="false">)</span></div> <p>is the usual chiral Dirac 
   operator.</p>

I was about to say that this is in fact no worse than the actual MathML as 
seen on the site you cited, but actually, it's better. It actually works 
in legacy UAs, for one! It also doesn't need any explicit namespaces, 
which in the original are very verbose.


> Issue 41 is about enabling decentralized parties to create their own 
> languages.  Taking options off the table prematurely and proposing 
> unusuable syntaxes are not consistent with furthering a constructive 
> conversation on the topic.

class="" isn't unusable. Indeed, the Microformats community has shown that 
it can be used as the basis for multiple quite detailed vocabularies 
successfully.


> I appologize that I don't quite have the same number of cycles to devote 
> to this issue as you have.  I am trying to keep up.

I don't have that many cycles. I've been spending my free time on this 
trying to get something that can address all use cases including yours, 
because, well, actually I'm not sure why. Several people have asked me to 
stop responding to you.

Since you have so far rejected all the proposals I have put forward, and 
since so far all the proposals you have put forward have only been 
incomplete proposals intended to foster discussion (paraphrasing what you 
said in an earlier message, sorry if it's not exactly what you said), 
could I instead suggest a new approach? Could you concretely describe your 
use case, make a full and complete concrete proposal (intended for the 
actual spec to use, instead of intended to foster discussion), and then, 
if people find problems with this proposal, actually address those 
problems and iterate your proposal until we have something that addresses 
the use cases and requirements that everyone has? It's what I've been 
trying to do so far but it hasn't worked. I think it is your turn to try.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 5 August 2008 04:51:03 UTC