Closed Bug 256084 Opened 20 years ago Closed 17 years ago

RDF and XUL Document confusion

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: xanthor+bz, Assigned: philor)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

Fix v.1
5.47 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

When a page is served with the application/rdf+xml media type, the XSLT
transformation doesn't occures.
When we chan the media type to application/xml, it works.

Reproducible: Always
Steps to Reproduce:
1. Open http://www.ultimatehosting.org/users/taupe/foaf.rdf
2. Open http://www.ultimatehosting.org/users/taupe/foaf.xml
3. Realise that even there are exactly the same files, the XSLT transformation
only occures on the second one.
Actual Results:  
No XSLT for application/rdf+xml

Expected Results:  
XSLT for application/rdf+xml

You can verifie on your local drive also, downloading the .rdf file, and then
renaming it to .xml.


I was told that this bug is related to Bug 256083 but I really don't know.

(Tested on Moz1.8a3 on Linux and win32)
It's a bit strange that RDF would end up as XUL, but in fact, that seems to 
happen.

Jst, bz, any idea why? Or just for histerical reasons?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Presumably this is so that the XUL content sink is used and creates proper
prototypes and the like...
bz, if you're referring to the use of RDF within xul templates, those use RDF as
created by the RDF service, which actually goes thru the nsRDFContentSink,
and doesn't generate a DOM or even a document at all.

This is just about the default document and viewer.

(I wonder if RDF should one day have a separate pretty printer, doing some kind of
N3 serialisation.)
> This is just about the default document and viewer.

Sure.  I'd guess the history of the comment at
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/build/nsContentDLF.cpp&rev=1.59&mark=461#461
is what we'd want here... anyone up for some CVS archeology?
Lets move this over to DOM Mozilla Extensions, seems to be the closest component
for this.

XUL is displayed in RDF Documents. At least if you believe the method names
in nsContentDLF. That's just plain wrong. Ok, the RDF Documents have a xul 
contract ID, but anyway.

I wonder if we want to do anything cool for RDF displayed in the browser, though.
No idea how right now, as people obviously use XSLT to style it for viewing, we
can't just send it off to something completely unrelated to a DOM, which would
be the right thing to do for RDF, IMHO. But anyway, I'm pretty sure that this
should go thru the XML content sink and not end up in XUL land.
Assignee: peterv → general
Component: XSLT → DOM: Mozilla Extensions
QA Contact: keith → ian
Summary: XSLT transformation doesn't work on application/rdf+xml files → RDF and XUL Document confusion
*** Bug 256083 has been marked as a duplicate of this bug. ***
Maybe we could detect whether XSLT/CSS is used or not and depending on that turn
pretty view on or off? (Checking the namespace of the root element might be a
good thing to do too.) Format it as N3 sounds like a nice idea.

(By the way, both examples mentioned in comment 0 refer to the XSLT document as
if it had a 'text/xsl' MIME type, while it actually has (and MUST have) a
'application/xml' MIME type.)
Keywords: testcase
Hardware: PC → All
The problem is, we do have an XML pretty-printer, working off of DOM content.
Which an RDF pp wouldn't do, so we would have to redirect to a different content
sink or something.
(The type="text/xslt" is ok, it's an IEism that we support. We advocate that one
doesn't confuse type with the MIME type of the style sheet though.)
(In reply to comment #4)
> > This is just about the default document and viewer.
> 
> Sure.  I'd guess the history of the comment at
>
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/build/nsContentDLF.cpp&rev=1.59&mark=461#461
> is what we'd want here... anyone up for some CVS archeology?

CVS is dating back to times predating the files in content, but I found 
something here, which is bug 43121, "pull XUL content model out of rdf.dll",
a waterson bug from back in 2001.

I bet we can now fix this for good.
attaching our discussion on irc...

<Jan> pike: that bug is fixed, isn't it?
<Pike> Jan: yes, but it is the reason why we use RDF documents to display XUL.
Or at least, that's what nsContentDLF claims
<Jan> pike: you mean CreateRDFDocument?
<Pike> yes
<Jan> pike: seems like it actually creates XUL documents
<Pike> yes, because there is no such thing as an RDF document
<Jan> yeah, so is it just misnamed?
<Pike> but it creates a XUL document for RDF, which keeps us from seeing XML
prettyprinting or XSLT for RDF files sent with application/rdf+xml
<Pike> once you point your browser to an RDF directly
<Jan> ah
<Jan> I'm looking at gRDFTypes
<Pike> yeah, it's scary
<Jan> rdf mimetypes could be moved to gXMLTypes
<Pike> yeah, and we should probably rename the rest
<Jan> sounds good
Blocks: 303252
Firefox's new "feedview" prettyprinter for RSS would like it much better if RSS
1.0 served as application/rdf+xml did get an XML DOM, rather than N3 or the
current XUL that it can't get at.
anyone have an answer to why when I download any extensions, or plugins from
Mozilla they never install anywhere?    

Not sure if I was supposed to comment here, just trying to be helpful, and thank
you so much :)

Gerri Smith
*** Bug 317571 has been marked as a duplicate of this bug. ***
Is there any news of progress on this bug?
*** Bug 354020 has been marked as a duplicate of this bug. ***
*** Bug 354529 has been marked as a duplicate of this bug. ***
*** Bug 360831 has been marked as a duplicate of this bug. ***
Attached patch Fix v.1 — — Splinter Review 
I'd be happier if I had a ghost of an idea why it was done that way in the first place, but, meh. That's what reviewers are for, no?

The URL field's a nice test, since it suddenly turns to XSLTed loveliness, but for straight XML-pretty-printing, http://www.w3.org/2006/time works, and for Firefox feed subscription UI, http://weblogs.mozillazine.org/roc/index.rdf
Assignee: general → philringnalda
Status: NEW → ASSIGNED
Attachment #257466 - Flags: superreview?(bzbarsky)
Attachment #257466 - Flags: review?(bzbarsky)
Comment on attachment 257466 [details] [diff] [review]
Fix v.1

of an idea why it was done that way

See earlier comments in this bug.  Only waterson knows.  I sure don't!

But this is the right change, imo.  r+sr=bzbarsky
Attachment #257466 - Flags: superreview?(bzbarsky)
Attachment #257466 - Flags: superreview+
Attachment #257466 - Flags: review?(bzbarsky)
Attachment #257466 - Flags: review+
layout/build/nsContentDLF.h 1.9
layout/build/nsContentDLF.cpp 1.80

Thanks, bz.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Any chance of getting this on the branch? Helps extension authors find RDF with their extensions.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: