forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [VOTE] Finalizing html-ihtml-ehtml
Date Fri, 09 Apr 2004 11:23:54 GMT

Collating the two mails from David.

David Crossley wrote:
> Nicola Ken Barozzi wrote:
>>and in the past there have been contrasting opinions, ...
> Those people do not seem to be around now. However the old
> discussion may have some relevant stuff. Can anyone point
> to the archives - i don't want to drag up any dispute,
> just see if anything useful for the current situation.

I don't have better pointers to give you than the ones you would find 
yourself with searching "ihtml" "html" "ehtml" "fix" "VOTE".

>>The goal is to make html files be treated as a source to clean, and 
>>xhtml files as a source to skin (ala ehtml).
>>1 - make .html extensions work as .ihtml
> Yes. Thanks for your description of cleaned html. That helped
> me to understand the issues.
>>2 - Add an .xhtml source extension that will be used also with xhtml2,
>>     and have unrecognized tags that can exist in the output percolate
>>     through the html output.
> When you say "unrecognised tags" i gather that you mean that stuff
> not explicitly dealt with by the stylesheets gets directly through
> to the output. Those tags are still valid XHTML. Am i right?

Correct. Basically we will be enhancing the output by skinning, not by 
filtering unrecognized tags (except style ones, as they don't follow the 
SOC principle), as they are still valid for the output. Of course they 
won't show in other outputs like PDF, but it's a reasonable limitation, 
given the advantages.

>>     This removes need for the multi-namespace support would instead
>>     force us to do relax-ng validation or no validation at all.
> What do you mean "force to do RNG validation"? Is that not a goal?

Not a near-term goal for me. I mean that this solution does not force us 
to do this change also now...

> Is multi-namespace support still possible down the track?
> I mean to ensure that we are not cutting off future stuff.

... but of course it does not block it later on. The good thing is that 
in essence it's independent of the RNG change, thus less traumatic.

>>3 - deprecate .ihtml and .ehtml
> Yes. There is no need when we have 1 and 2.
>>Reference for html-xhtml:

   ---8-<---8-<---8-<-- OTHER MAIL --8-<---8-<---8-<---8-<

David Crossley wrote:
 > Nicola Ken Barozzi wrote:
 >>Dave Brondsema wrote:
> <snip/>
>>> 1 & 3 we could do now. 2 should wait until the xhtml2 switch.
>>> Right?
>> Well, in fact no :-)
>> We can do (2) right now, but use XHTML1.0. When we switch to
>> XHTML2.0 as an intermediate format, it will be then trivial to add
>> it to the DTDs under XHTML.
 > Do you mean just switch the DOCTYPE declarations? And evolve the
 > stylesheets too i suppose. We would still need to support the old
 > XHTML1.0 and i gather that Sitemap matches that we have in place
 > respond to the Public Identifier, so it is well handled.

Yes, we would be just adding a new stylesheet for the new DTD, just as 
we do now for the xml extension.

> I do wonder if we might be painting ourselves into a corner by 
> depending on the doctype declaration. That ties us to DTDs because 
> the parser must resolve it.
> Sorry, this is disrupting the Vote thread, but i feel that it might
> be a key issue.

Hmmm... How does RELAXNG use the right schema? IIRC with the namespaces. 
But XHTML comes with a DTD... IIUC we will in fact need to configure the 
selector for the future RelaxNG, but in any case the concept remains.

>> Basically .xhtml will work exactly like xml works now. We could in
>> fact use the current .xml extensions, but xhtml has it's own
>> extension and media type, so I prefer to do as outlined above.
 > I do not quite understand the plan for our "xdocs" format.
 > Is that still the "intermediate format"? I was under the
 > impression that our xdocs schema was going to evolve to become
 > a subset of xhtml2. Are you suggesting that it will actually
 > *be* the full xhtml2?

Actually this plan is indipendent from the XHTML2 thing. In this vote 
thread the xdocs remain the intermediate format, and XHTML2 is inserted 
just because it will use the same .xhtml extension, to show that this 
proposal won't interfere with the future changes.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message