W3C home > Mailing lists > Public > public-html@w3.org > May 2010

Re: ISSUE-4 - versioning/DOCTYPEs

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 19 May 2010 17:35:08 +0200
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html@w3.org, Boris Zbarsky <bzbarsky@MIT.EDU>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Sam Ruby <rubys@intertwingly.net>
Message-ID: <20100519173508850260.af3f14b8@xn--mlform-iua.no>
Henri Sivonen, Wed, 19 May 2010 07:01:35 -0700 (PDT):
> "Sam Ruby" <rubys@intertwingly.net> wrote:

> "Leif Halvard Silli" <xn--mlform-iua@målform.no> wrote:
> 
>> Fact is that at least KompoZer and NVU produce Appendix C compatible 
>> XHTML for documents in text/html mode if the document has an XHTML 
>> DOCTYPE. Thus, KompoZer and NVU are dependent on the doctype in order
>> to produce XHTML. 
> 
> What KompoZer and NVu do is not a use case.

The use case is "an in-document and editor independent signal to create 
polyglot HTML5". Since you said you could be OK with using xmlns as 
such a trigger, I suppose we more or less agree about the use case. 
Documenting how things actually works, is otherwise held in high regard 
in this group. And it so happens that KompoZer - and other 
(non-mozilla) editors as well - look at the DOCTYPE. Sam, OTOH, has 
said that xmlns could also work as signal, and maintained that this 
could seem to work for human editors. Note that those that look at the 
DOCTYPE, will also add the xmlns - there is currently no established 
tradition to have it work the other way around. I agree that this is 
worth looking into, despite that it doesn't match how e.g. KompoZer 
currently works. The positive thing about this idea is that xmlns is 
semantic, whereas DOCTYPEs are just a rule set.
 
>>> Leif, are there additional use cases that I'm missing?
>> 
>> Authoring.
> 
> That's too vague to be evaluated as a use case.

I chopped  your own comments, to demonstrate that they all were about 
'serving', and offered a contrasting, chopped off reply were I said 
'authoring'. Otherwise, see comments above.

>> Validation. Being able to offer validation quickly.
> 
> That's vague, too. How does polyglotness enable validation (more) quickly?

I will answer a question that is relevant to my position: "How does a 
<!DOCTYPE html 'polyglot-signal'> enable validation more quickly?" 
Answer: Anyone that is able to create a DTD can create a validation 
service today. A DTD is a schema. For e.g. Validator.nu, we must wait 
for your excellent work. (Yes, DTD validation is in some ways more 
superficial than Validator.nu.)

>> Avoiding other versioning systems from develop.
> 
> Let's avoid using doctypes as a polyglot flag first and avoid 
> crossing the other bridges when we get there.

Well, may be.

>> Why does Mac OS X use use XML configuration files with Apple doctypes,
>> if DOCTYPEs are useless?
> 
> I don't know, but my scientific guess is: Because the developers of 
> the format had seen other XML formats use doctypes.

Or because they were at a bridge ...
 
>> KompoZer operates with a text/html DOM, but makes sure that it 
>> creates XHTML compatible output. 
> 
> So KompoZer doesn't support editing or even preserving XHTML+SVG or 
> XHTML+MathML?

There are no SVG editing tools in KompoZer. I think preserving works if 
there are no prefixed attributes in the document - at least no 
attributes that are prefixed with 'xml:'. I guess KompoZer et co has 
been too focused on text/html to get it to work application/xhtml+xml. 

Btw: being able to tell KompoZer to treat .html as .xhtml would be nice 
...
-- 
leif halvard silli
Received on Wednesday, 19 May 2010 15:35:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC