Re: [xml] Reordering of meta tags -- Bug?

[Tobias Reif <tobiasreif pinkjuice com>]

Daniel Veillard wrote:

> On Thu, Jul 17, 2003 at 06:19:31PM +0200, Tobias Reif wrote:
>
>>Daniel Veillard wrote:
>>
>> >   The node is (re-)created because your are serializing XHTML-1.0
>>
>>There are various issues with that behaviour.
>>
>   There is a zillion of issues with XHTML1, passing the encoding
> it's funky serialization rules (non normative because otherwise
> the XML group would have blocked it from REC) etc ...

Those other issues are not relevant here AFAICS.

>> > and
>> > in accordance to the XHTML-1.0 spec rules for serialization.
>>
>>I'm not sure if this is mandated by a normative section of a W3C rec.
>>Can you provide a URL and quote?
>>
>   http://www.w3.org/TR/xhtml1
>  if you remove the non-normative sections it's an empty shell

Where's the text mandating the current behaviour of libxml?
(mandating the insertion of elements by the serializer (plain serialzer 
not author or authoring tool))

>>xmllint --format also inserts the meta http-equiv if the document has
>>an XHTML 1 doctype.
>>
>   yes as I said, the serialization for XHTML1 does this.

Where is that specified? What are you referring to with "the 
serialization for XHTML1"?

>> > If you don't want this (and other serialization specific
>> > serialization
>> > rules) to occur remove the DOCTYPE indicating it's an XHTML-1.0
>> > document.
>>
>>Adding an element doesn't seem to be a minor detail of serialization,
>>but instead changes the document, it's information set, and the number
>>of elements.
>>
>   I know if you don't want this:
>     - either don't use XHTML DOCTYPE

Not an option.

>     - or don't use libxml2

May be the only option.

>     - or post-process the output

I need a pretty printer which does not add elements; a simple requirement.

I can't see why I should have to postprocess the output to fulfill this 
genaral and simple requirement.

>     - or write your own serialization layer

That would be a terrible waste of time, there exist good tools already.

I think the current behaviour is incorrect. If you don't change it, I 
might have to stop using xmllint etc, which would be sad.

>>Different details of serialization should not change the (canonical
>>version of the) document.
>>
>   Blahhh !

I'm not sure if I am willing to continue a discussion at this level.
The above complaint remains unaddressed.

> Read appendix C.

I did, many times, a long time ago.

Text inside []s inserted by me:
"This appendix summarizes design guidelines for authors [authors, not 
serializers] who wish their XHTML documents to render on existing HTML 
user agents [only those authors/scenarios, not the others]."

> If you disagree simply don't use XHTML1,

That doesn't make sense; XHTML can be used without ever reading or 
following App. C.

Appendix C is just an informative appendix, there are different ways to 
achieve "HTML compatibility". Even if I would agree with every point of 
Appendix C: not every XHTML 1.0 document needs to be "HTML compatible".
If I want to make a document follow the guidelines given in App C, I can 
change it *myself*, eg by adding the meta http-equiv line. It's not the 
job of the serializer AFAIK.

Scenario:
I have an XHTML 1 document. It does not have to be "XHTML compatible" in 
the way that App C describes. I want to pretty-print it. If I use 
xmllint --format, I will have one more element in this doc: Not what I 
want, and not what I expect from a pretty-printer.

> this is only a serialization cookbook for HTML-4.01 document seen as
> XML.
> Or don't use libxml2, that's another way,

You now suggested twice to stop using your software.
Overall I found it to be very useful, so I'd be happy if we could 
resolve this issue, so I can continue to use xmllint etc.

In summary:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

IMHO, xmllint --format should not insert the above line.

Why?

1. A pretty-printer should pretty-print, but it shouldn't add data.
(~ change nothing but (insignificant) white space)

2. If it's added for "HTML compatibility";
a) Not every XHTML doc needs to be "HTML compatible".
Not every HTML compatible XHTML doc wants/needs to / can say it
would be text/html.
Some people need application/xhtml+xml.
b) "HTML compatibility" is not a normative spec; there are various
ways to do it. I suggest to leave these decisions to the users.
At least turn it off per default, perhaps add an option for those
who want that line to be inserted.

3. If the doc is not HTML compatible, then the line is an error,
because
http://www.w3.org/TR/xhtml-media-types/#summary rightfully
states that XHTML (including 1.0) which is not "HTML compatible"
should not be sent/declared as text/html.

And most importantly:
http://www.w3.org/TR/xhtml-media-types/
"In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family
documents, and the use of 'text/html' SHOULD be limited to
HTML-compatible XHTML 1.0 documents."

Tobi

--
http://www.pinkjuice.com/