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

Ian Hickson <ian@hixie.ch> wrote on 08/04/2008 06:01:52 PM:
>
> Does that mean that issue 41 can now be considered resolved as far as you

> are concerned?
>
>    ISSUE-41
>    http://www.w3.org/html/wg/tracker/issues/41

No.  While I admire your energy and intensity, please forgive my use of
latin here: ignoratio elenchi.

Ian Hickson <ian@hixie.ch> wrote on 08/04/2008 08:07:52 PM:

> On Mon, 4 Aug 2008, Sam Ruby wrote:
> >
> > But Ian found another loophole.  A much bigger one.  I hadn't said that

> > usability was a requirement.
>
> So the class="" attribute solution _doesn't_ address your requirements?
Or
> does it? I'm confused. It seemed to me that you just said that it did.
>
> Is <div class="issue"> or <span class="price"> really hard to use? It
> seems to me that people have no problem using it in practice. Certainly
> relative to the number of people using class attributes and the number of

> people using namespace prefixes, I see far less confusion from people
> using class attributes, yet you were pushing namespace prefixes as a
> solution that did address your use case.

First, that's a mischaracterization.  The most I have ever argued for is
not to take namespace prefixes off the table prematurely.

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

> I'm trying to address your use case here, it would be helpful if you
> didn't just dismiss my attempts at doing so.

If you can show a usable syntax for the above page given the notation you
suggested, then my appologies.

> In an earlier e-mail when we were discussing other mechanisms to address
> your use case, I wrote the following. You never replied, dismissing my
> attempts at attempting to address your use case. If you are going to
claim
> that I'm dismissing your feedback, the _least_ you could do is respond to

> my questions about said feedback.

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.

> Can you answer the following?:
>
> > > > > [ analysis showing why I concluded that not having a namespace
> > > > > prefix mechanism is better than having one, even if it means that
> > > > > we our extension mechanism can't use tag names ]
> > > >
> > > > I would be a fool to say that indirection syntaxes don't have
> > > > problems. The only thing that would be a bigger mistake would be to

> > > > not build in a mechanism for distributed extensibility.
> > >
> > > Why would it be a bigger mistake? As far as I can tell, from the
> > > analysis above, it would be at most an equally big mistake, and
likely
> > > a lesser mistake.
> >
> > What is clear that you have decided this.  And base this decision on a
> > number of anecdotes that you regularly pull out.
>
> Ok, but you apparently have concluded the opposite, so what do you base
> your decision on? How is my analysis flawed?

First, I have not made a decision.

I certainly believe that enabling others to experiment would be a big win.
Perhaps that can be done with an indirection syntax.  Perhaps it can not.
If it does require an indirection syntax, perhaps there are ways to
mitigate the issue.

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.

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

- Sam Ruby