PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3134 *** shadow/3134 Wed Aug 15 12:34:07 2001 --- shadow/3134.tmp.4779 Tue Aug 21 12:09:40 2001 *************** *** 42,44 **** --- 42,69 ---- ------- Additional Comments From [EMAIL PROTECTED] 2001-08-15 12:34 ------- The issue appears to apply to the cases of "include" and "redefine". + + + ------- Additional Comments From [EMAIL PROTECTED] 2001-08-21 12:09 ------- + Hi Takuki, + + There's no doubt that Xerces1's entity resolution is not optimal. But I don't + think the change you propose here would be a generally good idea. + + The main reason for this is this: If Xerces hands your application a relative + URI, your application can make it absolute if it so chooses. But if Xerces + makes a mistake while building an absolute URI, there's no way for you + application to figure out where things went wrong. + + If you look at the code in TraverseSchema that you propose to call, it expands + the URI relative to the Java property user.dir. There's no reason why this + should in general correspond to the directory relative to which the path was + intended to be; nor is there anything precluding your EntityResolver from doing + the same thing. + + My suggestion is that, if you want this behaviour, simply copy the relevant + Xerces methods into your own EntityResolver and absolutize the URI that Xerces + passes you accordingly. + + Cheers, + Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
