57360 - RDF content sink generates incorrect resource URIs

Status: VERIFIED FIXED

(Core Graveyard :: RDF, defect, P3)

Description

[Chris Waterson]

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.

Comment 1

[Chris Waterson]

Attachment: proposed fix

Comment 2

[Chris Waterson]

Attachment: RDF test file

Comment 3

[Chris Waterson]

Attachment: sample XUL file that uses I18n-ish RDF/XML

Comment 4

[Chris Waterson]

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. :-(

Comment 5

[Chris Waterson]

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

Comment 6

[Robert John Churchill]

Looks dandy, r=rjc

Comment 7

[Erik van der Poel]

Does your fix assume that RDF documents are always in UTF-8?

Comment 8

[Chris Waterson]

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

[Alec Flett]

simple enough, sr=alecf

Comment 10

[Chris Waterson]

fix checked in.

Comment 11

[Tom Everingham]

verified:  6/27/01 builds winNT 4, Linux rh6, Mac os9