Re: SVG and MathML in text/html

Hey guys,

It seems that there is no easy way to include other vocabularies into  
text/html assuming that:
1) You want the resulting docs to conforming
2) You want the resulting docs to be testable for conformance (using  
code, not manually)
3) You want to be able to support emerging technologies
	Henri's point that we've only seen two additional element sets is not  
entirely useful. In the broader web, I agree that new languages are  
likely to be infrequent. However in corporate settings, where all the  
browsers are controlled, other technologies could very well become  
common.

In SVG, you have the foreignObject. Why not introduce something  
similar here? Would this not provide adequate isolation to allow  
validation code to work?

Just $0.02 from a lurker
Adam


> On 11-Mar-08, at 7:59 AM, Henri Sivonen wrote:
> On Mar 10, 2008, at 23:06, Julian Reschke wrote:
>
>> Henri Sivonen wrote:
>>>> Atom, for instance, works much better.
>>> http://hsivonen.iki.fi/atom-xhtml/
>>
>> It does work better.
>>
>> Yes, there may be clients that are broken.
>
> And why might that be? Perhaps XML is tough.
>
>>> Putting all the element names from the Web platform languages  
>>> (XHTML, SVG, MathML) into a single space of XML element names  
>>> without any URI binding mechanism. That is, if HTML defined  
>>> "table", it is taken and MathML should define "mtable".
>>
>> Doesn't scale. How do you add a new vocabulary? Don't say you don't  
>> need to in the future.
>
> In the past decade, the vocabulary of the Web platform has been  
> extended by a whopping two additional element sets: SVG and MathML.  
> Next XBL2 may join the platform.
>
> Given that this is the actual rate of vocabulary growth we got  
> *with* Namespaces in XML in place, it seems clear to me that as far  
> as the Web platform goes, Namespaces in XML is premised on a totally  
> wrong projection of the rate of growth and, thus, solves a problem  
> we'd not really be having.
>
> In the case of MathML, the convention of starting element names with  
> "m" would already be sufficient for avoiding collisions with HTML.  
> As far as MathML goes, Namespaces in XML is just a superfluous  
> complication.
>
> In the case of SVG, the element name overlap with HTML is small and  
> mostly about duplicating the elements. Had Namespaces in XML been  
> absent, SVG could easily have been designed not to clash with HTML  
> in a bad way.
>
>>>>>> Maybe it’s because I’m used to writing SVG, but I really don’t  
>>>>>> have a problem with the concept of mixed namespace content.
>>>>> I have a problem with namespace URIs every single time I need to  
>>>>> deal with XHTML, SVG, etc. I always have to waste time looking  
>>>>> up and URI to copy and paste because trying to go by memory and  
>>>>> getting it wrong (which year? trailing slash?) would waste even  
>>>>> more time.
>>>>
>>>> I fail to see how this is a problem. Is copy & paste too hard?
>>> Yes, when the plausible alternative is not having to do that.
>>
>> Well, short names require a central registry.
>
> A central registry is a good thing in order to avoid a Babel of  
> languages with no coherent common feature set for authors to rely on.
>
>> Doesn't scale as well as URIs. See the related microformats  
>> discussions.
>
> http://www.w3.org/TR/ seems to scale well enough to cover HTML, SVG  
> and MathML.
>
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>
>

Received on Wednesday, 12 March 2008 04:13:26 UTC