Closed Bug 101653 Opened 23 years ago Closed 23 years ago

style not rendered for XML docs

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 88614

People

(Reporter: powers.jason, Assigned: bc)

References

(
URL
)

Details

this w3.org xml page doesn't render styles in the browser. It displays as plain text. Is their document wrong, or the browser?
Probably dup of bug 88614 or bug 92706.
We are doing the right thing: the XML served does not contain any stylesheets. This could be one more instance of bug 88614, i.e. the W3C server is confused because we send text/xml in the accept headers. However, this could be intended as well in this case. Jason, where did you find this link? The link specifically points to an XML document, so I would expect to receive XML (unlike in bug 88614 where the URL points to an official spec without the XML suffix).
Ok, I got an email from Jason. If you go to http://www.w3.org/TR/REC-xml which is the XML spec, and click to see any of the previous versions of the spec you get the raw XML. Over to Evangelism.
Assignee: heikki → bclary
Status: UNCONFIRMED → NEW
Component: XML → English: US
Ever confirmed: true
Product: Browser → Tech Evangelism
QA Contact: petersen → zach
Version: other → unspecified
http://www.w3.org/TR/REC-xml has the current xml spec, and a link to the old one. BOTH the old one and the "XML" link after "Current version:" come up as plain text. If it's their server, then there's no problem with Mozilla. But if it isn't... Maybe there's a good torture test somewhere for xml with stylesheets? I was trying to figure out what Mozilla will support - I need to know when this browser's ready for my company to install, and I think they're pushing towards going with the w3c specs.
Mozilla/Netscape 6 have excellent XML+CSS support, and just about usable XSLT support if you know what to avoid. But this klind of discussion belongs to the newsgroups, I'll post a reply to the newsgroup netscape.public.mozilla.xml, the best news server for that feed would be news.mozilla.org.
perl head http://www.w3.org/TR/2000/WD-xml-2e-20000814 200 OK Cache-Control: max-age=31536000 Connection: close Date: Wed, 26 Sep 2001 18:42:16 GMT Accept-Ranges: bytes Server: Apache/1.3.6 (Unix) PHP/3.0.11 Vary: negotiate, accept, accept-charset Content-Length: 201959 Content-Location: WD-xml-2e-20000814.html Content-Type: text/html; charset=iso-8859-1 ETag: "13c99a-314e7-399873c2;3b2e051b" Expires: Thu, 26 Sep 2002 18:42:16 GMT Last-Modified: Mon, 14 Aug 2000 22:33:38 GMT Client-Date: Wed, 26 Sep 2001 18:41:40 GMT Client-Peer: 18.7.14.127:80 P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml" TCN: choice Looks like to me that their invariant URI scheme defaults to text/html and they do not properly report XML documents without an .xml extension as XML. Will someone who knows who to contact, please take this an all W3 evangelism bugs?
Bob, this site does agent sniffing and send different pages depending on which user-agent is accessing. Try this clever URL sniffer with different browser: http://webtools.mozilla.org/web-sniffer/ With the latest Netscape branch build (0.9.4), I get the following headers back: HTTP/1.1 200 OK Date: Wed, 26 Sep 2001 19:00:44 GMT Server: Apache/1.3.6 (Unix) PHP/3.0.11 Content-Location: WD-xml-2e-20000814.xml Vary: negotiate, accept, accept-charset TCN: choice P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml" Cache-Control: max-age=31536000 Expires: Thu, 26 Sep 2002 19:00:44 GMT Last-Modified: Mon, 14 Aug 2000 22:17:39 GMT ETag: "640398-3032d-39987003;3b2e051b" Accept-Ranges: bytes Content-Length: 197421 Connection: close Content-Type: text/xml; qs=0.9 But if access this page with Comm 4.x, I get the kind of headers you quote above.
Kat. Thanks. Nifty tool indeed. Looking at the source, I don't see anything related to specifying CSS or XSLT anywhere or I am missing the point here too? It is interesting to note that IE5.5SP2/Win2k croaks on http://www.w3.org/TR/1998/REC-xml-19980210.xml.
OK I sent all this (including the problem pages and a link to this page with your responses) to the WC3's Webpage Technical Issue contact. You-all have been very helpful, and I figured if I sent it in to w3c for you, you could close this bug and get back to business. I'll watch that newsgroup for torture tests, and if nothing interesting comes up, I'll just build one myself. As of .94, Mozilla is stable enough for my users to upgrade from Netscape 4, and we need it (and xml-css) if we're gonna exploit some of the new things we're looking at doing with our database. If I can successfully update the users at my .org (http://ecog.dfci.harvard.edu) to Mozilla (or we may wait until Netscape 6.2 or .3), the Dana Farber Cancer Institute won't be far behind. I've been testing this browser since .6, and it's great to watch it grow. I like the Multizilla plugin, maybe it should be incorporated?
Thanks, Jason. I think Heikki was right in his analysis. W3C sends text/xml documents in this case to Mozilla/NS6.x but forgets to include a stylesheet or some other styling info. Comm 4.x and IE5, etc. are served HTML pages with a proper stylesheet URL included.
Additional Info. As I commented in Bug 88614, this is due to Mozilla side bug. We are sending an accept header in which text/html is ranked lower than text/xml. This is why we are served XML pages. If we want HTML pages, then we need to fix Bug 88614. A workaround was posted to Bug 88614.
No, no, no! Mozilla is correct. W3C is wrong. Our accept header is correct: we prefer XML over HTML. The W3C server has at least two problems: 1) It serves us XML without stylesheet, which makes no sense and 2) according to W3C the HTML version of the spec is the normative version and therefore they should ALWAYS serve the HTML version of a spec. *** This bug has been marked as a duplicate of 88614 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
yes
Status: RESOLVED → VERIFIED
I am re-opening this bug because the pages mentioned in this bug are still broken and Bug 88614 has turned into a related but different issue at the moment. I think we need to continue evangelizing work on the pages reported here.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
No, this is the same issue: the server is reacting wrongly to our Accept-header. There does not need to be an open bug for every W3C page out there that reacts wrongly... *** This bug has been marked as a duplicate of 88614 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
verif
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.