RDF content sink generates incorrect resource URIs

VERIFIED FIXED in mozilla0.9

Status

P3
minor
VERIFIED FIXED
18 years ago
2 months ago

People

(Reporter: waterson, Assigned: waterson)

Tracking

Trunk
mozilla0.9

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

18 years ago
If the RDF content sink loads an RDF/XML file from a URL that contains UTF-8
characters, or if any of the "ID" or "about" attributes in the file contain
non-ASCII characters, it will generate an incorrect graph.

In the former case, it will incorrectly treat the UTF-8 encoded URL as ASCII. In
the latter case, it will (apparently, by design) just ignore the ID or about
attribute altogether an "make one up". (What was I thinking?)

I'll attach a patch that fixes these issues. I discovered them while trying to
debug some other random I18n bug.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 1

18 years ago
Created attachment 17562 [details] [diff] [review]
proposed fix
(Assignee)

Comment 2

18 years ago
Created attachment 17563 [details]
RDF test file
(Assignee)

Comment 3

18 years ago
Created attachment 17564 [details]
sample XUL file that uses I18n-ish RDF/XML
(Assignee)

Comment 4

18 years ago
To test the latter problem,

1. Click on the "sample XUL file that uses I18n-ish RDF/XML" attachment.
2. Wait a second or two for the RDF/XML to load.
3. You should see a table with two rows; if the first row says "Introduction to
JavaScript" then the bug is fixed.

I don't have a test case for the former problem. :-(
(Assignee)

Comment 5

18 years ago
nhotta, momoi: another data point for I18n-lame RDF. Found this last night while
working on that other AIM bug.

Comment 6

18 years ago
Looks dandy, r=rjc

Comment 7

18 years ago
Does your fix assume that RDF documents are always in UTF-8?
(Assignee)

Comment 8

18 years ago
No. It assumes that by the time the document has reached the content sink, it
has been promoted to UCS-2 from whatever character set encoding it was
originally provided in.

But, it *does* assume that the document's base URL is encoded in UTF-8. This is
what we do now with all document, IIRC.

Comment 9

18 years ago
simple enough, sr=alecf
(Assignee)

Comment 10

18 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 11

18 years ago
verified:  6/27/01 builds winNT 4, Linux rh6, Mac os9
Status: RESOLVED → VERIFIED

Updated

2 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.