Re: several messages about New Vocabularies in text/html

Ian Hickson wrote on 04/02/2008 11:07:37 PM:
>
> On Wed, 2 Apr 2008, Sam Ruby wrote:
> >
> > To explain the motivation, it helps if I start at the beginning.
>
> I understand the problem. It's the solution I don't understand.

Each time I have attempted to describe a solution in the past, it has
turned out that we were trying to address different problems.  Your
continued preocupation with the number of elements in the MathML namespace
indicates to me that we still aren't yet on the same page.  So please
forgive me if I want to take this a bit slowly this time.

Here is a fairly detailed proposal:

http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

That proposal had different advantages and disadvantages than one based the
use of default namespaces.  Or, if we want, we could explore one that is
based on Anne's XML5 project which supports both syntaxes.

But, for the moment, lets see if we can come up with a proposal that
handles one document successfully.  If we can get that far, then perhaps we
have something we can build upon.

> > If there is a new state, there needs to be a trigger.  You've rejected
> > <math> as a simple trigger.  Perhaps <svg> would work.  Perhaps not.
> > In prior discussions you rejected xmlns attributes as a trigger.  The
> > overwheling number of problematic xmlns attributes at that time had a
> > value of "".  Others had values that I did not recognize.  Or the XHTML

> > namespace.
> >
> > Any trigger has the potential for generating potential false positives.

> > In the case of MathML and SVG, it migth be useful to see if xmlns
> > attributes with the specific values specified for those standards
> > generates any false positives.  In particular, it would be clearly be
> > problematic if such an tag were not closed.  Let's proceed under the
> > assumption that such a trigger can be found.
>
> This is the assumption that I have the most trouble with in your e-mail.

If we have a new state, having no way to enter that state would completely
miss the point.

> Even if we find such a trigger, it doesn't solve the problem, because if
> someone (author A) using a new browser writes a page that uses this
> feature, and then someone (author B) using an old browser copies and
> pastes from A's page into his page, accidentally including the trigger,
> the second page will look fine to most users, but to the users of the new

> browser, it will be broken.

As Henri and Julian and perhaps others have pointed out, this requirement
makes all solutions impossible.  So we simply need to work on that problem
first.

> > The one key remaining difference is that the value of the namespace for

> > all these elements is wrong.  If, in this new mode, the value of
> > attributes named 'xmlns' (note: without a colon, i.e., not an xmlns:
> > prefix) were respected on that element, and all DOM nodes which are
> > created in this parsing phase which do NOT have an xmlns attribute
> > simply copy the value of the namespace of the parent, then you will
have
> > a DOM tree that, while incorrect for RDF and DC and SODIPODI and
> > INKSCAPE elements and attributes, may produce the desired graphic.
> > Feel free to challenge that assumption. But if this turns out to be
> > true, then the amount of specific parsing logic necessary to support
> > this document is fairly small and surgical.
>
> As you yourself point out, your proposal would need to be additionally
> changed to support CDATA blocks and case-sensitive tag and attribute
names
> in the parser, presumably triggered on the the presence of this
> aforementioned mythical trigger. For SVG we would also need to somehow
> support namespaced attributes, though I don't know how we'd do that
> (xlink:href in particular). We'd also need to define how to process HTML
> or other namespaces nested in the block covered by this trigger, as well
> as defining how to handle mis-nested tags in this mode.

I would be glad to do this.  Again.  But it seems pointless to do so if we
can't even agree that it is even possible to enter a new state, let alone
how to do so.

I maintain that matching on an attribute named "xmlns" with a value of "
http://www.w3.org/2000/svg" on an element otherwise unknown to HTML5 is an
approach that would (a) yield a statistically insignificant number of false
positives, (b) enable us to trigger the transition to a new state, and (c)
would serve as a model for how new vocabularies are to be introduced.

Once we have made that small baby step, we can eliminate a lot of
unnecessary exploration.  You recently gave a list of MathML elements which
can be a priori determined to be void.  If MathML can make use of this same
new state that we need to create for SVG anyway, and if the requirement to
support SVG makes having a list of elements to be an unworkable solution,
and we find a workable solution to that problem, then we don't need that
list of MathML elements.

So can we provisionally agree on a new state, and how how we are to support
the one document I identified?

- Sam Ruby