Closed
Bug 32842
Opened 26 years ago
Closed 26 years ago
FEATURE: Implement XML Base
Categories
(Core :: XML, defect, P3)
Core
XML
Tracking
()
VERIFIED
FIXED
People
(Reporter: hjtoi-bugzilla, Assigned: hjtoi-bugzilla)
References
Details
Attachments
(2 files)
|
7.31 KB,
patch
|
Details | Diff | Splinter Review | |
|
857 bytes,
application/x-gzip
|
Details |
XML Base is a W3C WD (in Final Call):
http://www.w3.org/TR/xmlbase
XML Base is similar to the base attribute in HTML. It is also a prerequisite for
XLink.
| Assignee | ||
Comment 1•26 years ago
|
||
| Assignee | ||
Comment 2•26 years ago
|
||
The above patch should have the XML Base logic implemented, as far as I can
tell. What remains to be done is to convert the Unicode string to ??? encoding
that fits into char*, and then doing URL-escaping (i.e. escape characters that
are illegal in a URL). nsIIOService has an Escape function, but the part I do
not yet know how to do is the conversion to something (what?) first.
NOTE: The patch also fixes an error in the simple XLink support. Without this,
if the value of href is "", we reload the doc.
Speed could also be optimized, for example it computes the URI every time it is
asked for and it does not even cache the service. I do not know if this is a big
deal, because it is still pretty fast and this is mostly needed when the user
moves the cursor on a link or clicks a link.
What is good is that it does not add stuff to the content node. Even after
optimization it shouldn't do this. If we want to avoid future computation we
should probably store previously computed values into nsXMLDocument.
| Assignee | ||
Comment 3•26 years ago
|
||
Bummer, I can't create attachments on Linux... Maybe Bugzilla is drunk. I have
created an XML file that tests XML Base and Simple XLink together.
Anyway, I noticed one case where GetXMLBaseURI hangs. Delete "continue;" and you
are set.
| Assignee | ||
Comment 4•26 years ago
|
||
| Assignee | ||
Comment 5•26 years ago
|
||
I now have CVS account, assigning XML linking related bugs to me
(heikki@citec.fi).
Assignee: nisheeth → heikki
| Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 6•26 years ago
|
||
Patches checked in. I will still need to figure out the URL escape thing and
then I can mark this fixed.
| Assignee | ||
Comment 7•26 years ago
|
||
I am marking this fixed although I do not think we correctly handle all illegal
characters in URLs. In fact, I do not believe we handle them properly ANYWHERE!
After asking about this from ftang@netscape.com, he said this is what to do:
1. Get the document encoding (nsIDocument has a method for this).
2. Use the nsTextToSubURI (?) interface to ConvertAndEscape Unicode
to URL string
I do not believe this works. First of all, the ConvertAndEscape method first
converts the Unicode string so that it fits into char*. For this it needs the
encoding. But what if the encoding is UTF-16? Even with UTF-8 I think this is a
problem, because that Escape part does not know about UTF stuff. It just thinks
all characters are between 0-255 and it does its subsitution. If we had a UTF-8
string with a multibyte character, each byte would now be separately escaped.
Maybe this could work, but I do not see how.
So, I did not do this. What I do is:
nsCAutoString str;
str.AssignWithConversion(unicode_string);
and then pass that str into the NewURI functions that seem to escape illegal URL
chars as well.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•