|
»
»
»
»
Re: XMLReader version 1.14 issues
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: XMLReader version 1.14 issues
by Alejandro Abdelnur-2
::
Rate this Message:
MMhhh, let me see if I can refactor the constructors so you can reuse
the current one with content-type=NULL. On 6/24/07, Jacob Kjome <hoju@...> wrote: > > Hi Alejandro, > > I just took a look at the latest changes in XMLReader and noticed > that you only added a new constructor for creating "a Reader using an > InputStream and the associated content-type header", but not for > creating "a Reader for a raw InputStream". For my purposes, I'd use > the latter, except it doesn't exist. I added it to my own version, > but figure that if it's useful to me it's probably useful to others > and may as well be in the official version of XMLReader. Thoughts? > > BTW, you didn't add a javadoc "@param" entry for defaultEncoding and > the javadoc for constructors taking a boolean "lenient" parameter > probably shouldn't state that "this constructor is lenient regarding > the encoding detection", since it depends on what the user passes to > the constructor. There's also a few javadoc spelling errors, such as > "an" instead of "and". No big deal, but I thought I'd mention it. > > All in all, great stuff! > > Jake > > At 12:27 AM 6/2/2007, you wrote: > > > >Thanks for addressing the issues and for the explanations! > > > >Jake > > > >At 09:47 AM 6/1/2007, you wrote: > > >Jacob, > > > > > >This got lost in my inbox, while working on the XmlReader I ran across > > >it. Sorry for the delay. > > > > > >On your comment on line #390, you are right it should be bomEnc. > > > > > >On your comment on line #425, is US_ASCII (HTTP content type declares > > >a MIME of text type and XML sub-type. There is not HTTP Content-type > > >charset encoding information. The charset encoding is US-ASCII. Refer > > >to RFC 3023 Section 3.1. Text/xml Registration.) > > > > > >On having default encoding per instance, keeping backwards > > >compatibility we can add a constructor that takes an instance default > > >encoding. All other constructors would use the static default > > >encoding. > > > > > >A > > > > > > > > >On 5/16/07, Jacob Kjome <hoju@...> wrote: > > >> > > >> Maybe the 3rd time's the charm? I saw there was an update to > > >> XMLReader so I thought I'd remind Rome developers of my 1.14 > > >> findings. They are still entirely relevant. Please pay special > > >> attention to the possible bugs I pointed out. I would hope you'd be > > >> interested in them. If you think I'm out to lunch, please say > > >> so. Otherwise, I think these are things that ought to be addressed > > >> rather than ignored. You can read below or view the whole thread in > > >> the archives.... > > >> > > >> https://rome.dev.java.net/servlets/ReadMsg?listName=users&msgNo=1251 > > >> > > >> > > >> Jake > > >> > > >> At 01:20 AM 3/9/2007, you wrote: > > >> > > > >> >Now that there's a bit more activity on the Rome list, any comments > > >> >on my email from a few weeks ago? See below... > > >> > > > >> >Jake > > >> > > > >> >At 07:16 PM 2/17/2007, you wrote: > > >> > > > > >> > >I tried sending this directly to the Rome developers a couple weeks > > >> > >ago, but received no response. So, I finally signed up for a > > >> > >dev.java.net account to see if I would get a response on the official > > >> > >list. Here's what I wrote..... > > >> > > > > >> > > > > >> > >My name is Jacob Kjome and I'm the maintainer of the XMLC project [1] > > >> > >where we use a modified version of your XMLReader [2]. I modified it > > >> > >to use gnu-regexp, since that's what XMLC uses for Regex and it also > > >> > >allows the class to be used in JDK's previous to 1.4. Anyway, that's > > >> > >the background. > > >> > > > > >> > >I've been trying to keep things in sync with your version, so I look > > >> > >at Rome's version every once in a while to see what's changed. The > > >> > >last few changes have been fine. But this 1.14 change seems odd to > > >> > >me (with at least one reasonably clear bug, explained below). It > > >> > >provides for setting a static default encoding. Interestingly, I had > > >> > >noticed this lack of a user-defined-default deficiency early on. In > > >> > >XMLC's version, I added the ability to pass a custom default encoding > > >> > >into a couple of the constructors, with an internal pre-set default > > >> > >of "UTF-8" if the default passed to the constructor is > > >> > >null. Effectively, this provides the same functionality as you've > > >> > >added. However, the fact that XMLC's version provides per-instance > > >> > >encoding defaulting makes it more flexible, as the preferred default > > >> > >value may change from use-to-use. Granted, this means more > > >> > >constructor arguments (for 2 constructors) and passing around the > > >> > >values to the internal static methods, but the flexibility is worth > > >> > >it and necessary in my use-case. > > >> > > > > >> > >I'm not telling you that you have to change because of my needs. I > > >> > >will always use a separate copy because of my need to use gnu-regexp > > >> > >instead of JDK1.4 regex. But it makes life easier if the differences > > >> > >between XMLC's version and Rome's version are kept to a minimum so I > > >> > >can keep up with additions and bug fixes easily. I figure if I can > > >> > >convince you to do it the way I've done it, it will make my life > > >> > >easier and maybe, if you agree with the way I've implemented it, > > >> > >benefit the Rome project at the same time. So, if you could take a > > >> > >moment to review the latest version of XMLC's XMLReader [2] and > > >> > >compare it against Rome's latest version, that would be great. I've > > >> > >made every attempt to keep white-space formatting in-line with Rome's > > >> > >version, so a simple diff should provide you with a clean and clear > > >> > >look at the important differences between our versions. > > >> > > > > >> > > > > >> > >Additionally, it appears that you've introduced at least one bug in > > >> > >the latest 1.14 version. Take a look at line #390. > > >> > > > > >> > >It currently is... > > >> > > encoding = (_defaultEncoding == null) ? UTF_8 : > > >> >_defaultEncoding; > > >> > > > > >> > >I think it should be.... > > >> > > encoding = bomEnc; > > >> > > > > >> > >You've already checked that "bomEnc" is equal to "UTF-8". Why would > > >> > >you then apply a default encoding rather than "bomEnc"? > > >> > > > > >> > > > > >> > >I have more of a question on line #425. Wouldn't defaulting to > > >> > >"US-ASCII" be better than a static default, which would more than > > >> > >likely be "UTF-8"? While XMLC's XMLReader uses the default encoding > > >> > >in most other applicable places, it leaves this one alone. I'm not > > >> > >100% sure what the most appropriate choice is here, but I lean toward > > >> > >"XMLReader knows better than the user providing the default" in this > > >> > >case where I defer to the user in all other cases where I need a > > >> > >default. I appreciate any advice you provide. > > >> > > > > >> > > > > >> > >There's also a possible pre-existing bug. Right after line #502, > > >> > >shouldn't the bytes be unread just as they are on lines #493, #498, > > >> > >and #506? I'm not sure about this one? I defer to your expertise, > > >> > >but I thought I'd point it out just in case you just hadn't > noticed it. > > >> > > > > >> > > > > >> > >[1] http://forge.objectweb.org/projects/xmlc/ > > >> > >OR http://www.enhydra.org/tech/xmlc/ > > >> > >[2] > > >> > > >http://cvs.xmlc.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc > > >> > >/modules/xmlc/src/org/enhydra/xml/io/XmlReader.java > > >> > > > > >> > > > > >> > >Jake > > >> > > > > >> > >--------------------------------------------------------------------- > > >> > >To unsubscribe, e-mail: users-unsubscribe@... > > >> > >For additional commands, e-mail: users-help@... > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> >--------------------------------------------------------------------- > > >> >To unsubscribe, e-mail: users-unsubscribe@... > > >> >For additional commands, e-mail: users-help@... > > >> > > > >> > > > >> > > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscribe@... > > >> For additional commands, e-mail: users-help@... > > >> > > >> > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: users-unsubscribe@... > > >For additional commands, e-mail: users-help@... > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: users-unsubscribe@... > >For additional commands, e-mail: users-help@... > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
|
|
XMLReader mods
by Jacob Kjome
::
Rate this Message:
I see you are looking for comments prior to a new release. So, will this issue
(see your - Alejandro - comment below) be addressed before a new release? You can see the changes I've made to my own version, which is synced to the 1.18 (latest) version of XMLReader in Rome... http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc/modules/xmlc/src/org/enhydra/xml/io/XmlReader.java Jake Jacob Kjome wrote: > > At 02:43 AM 6/27/2007, you wrote: > >MMhhh, let me see if I can refactor the constructors so you can reuse > >the current one with content-type=NULL. > > > > Any chance you will get around to this soon? > > Jake > > >On 6/24/07, Jacob Kjome <hoju@...> wrote: > >> > >> Hi Alejandro, > >> > >> I just took a look at the latest changes in XMLReader and noticed > >> that you only added a new constructor for creating "a Reader using an > >> InputStream and the associated content-type header", but not for > >> creating "a Reader for a raw InputStream". For my purposes, I'd use > >> the latter, except it doesn't exist. I added it to my own version, > >> but figure that if it's useful to me it's probably useful to others > >> and may as well be in the official version of XMLReader. Thoughts? > >> > >> BTW, you didn't add a javadoc "@param" entry for defaultEncoding and > >> the javadoc for constructors taking a boolean "lenient" parameter > >> probably shouldn't state that "this constructor is lenient regarding > >> the encoding detection", since it depends on what the user passes to > >> the constructor. There's also a few javadoc spelling errors, such as > >> "an" instead of "and". No big deal, but I thought I'd mention it. > >> > >> All in all, great stuff! > >> > >> Jake > >> > >> At 12:27 AM 6/2/2007, you wrote: > >> > > >> >Thanks for addressing the issues and for the explanations! > >> > > >> >Jake > >> > > >> >At 09:47 AM 6/1/2007, you wrote: > >> > >Jacob, > >> > > > >> > >This got lost in my inbox, while working on the XmlReader I ran > across > >> > >it. Sorry for the delay. > >> > > > >> > >On your comment on line #390, you are right it should be bomEnc. > >> > > > >> > >On your comment on line #425, is US_ASCII (HTTP content type > declares > >> > >a MIME of text type and XML sub-type. There is not HTTP > Content-type > >> > >charset encoding information. The charset encoding is US-ASCII. > Refer > >> > >to RFC 3023 Section 3.1. Text/xml Registration.) > >> > > > >> > >On having default encoding per instance, keeping backwards > >> > >compatibility we can add a constructor that takes an instance > default > >> > >encoding. All other constructors would use the static default > >> > >encoding. > >> > > > >> > >A > >> > > > >> > > > >> > >On 5/16/07, Jacob Kjome <hoju@...> wrote: > >> > >> > >> > >> Maybe the 3rd time's the charm? I saw there was an update to > >> > >> XMLReader so I thought I'd remind Rome developers of my 1.14 > >> > >> findings. They are still entirely relevant. Please pay special > >> > >> attention to the possible bugs I pointed out. I would hope > you'd be > >> > >> interested in them. If you think I'm out to lunch, please say > >> > >> so. Otherwise, I think these are things that ought to be > addressed > >> > >> rather than ignored. You can read below or view the whole > thread in > >> > >> the archives.... > >> > >> > >> > >> > https://rome.dev.java.net/servlets/ReadMsg?listName=users&msgNo=1251 > >> > >> > >> > >> > >> > >> Jake > >> > >> > >> > >> At 01:20 AM 3/9/2007, you wrote: > >> > >> > > >> > >> >Now that there's a bit more activity on the Rome list, any > comments > >> > >> >on my email from a few weeks ago? See below... > >> > >> > > >> > >> >Jake > >> > >> > > >> > >> >At 07:16 PM 2/17/2007, you wrote: > >> > >> > > > >> > >> > >I tried sending this directly to the Rome developers a > couple weeks > >> > >> > >ago, but received no response. So, I finally signed up for a > >> > >> > >dev.java.net account to see if I would get a response on > >the official > >> > >> > >list. Here's what I wrote..... > >> > >> > > > >> > >> > > > >> > >> > >My name is Jacob Kjome and I'm the maintainer of the XMLC > >project [1] > >> > >> > >where we use a modified version of your XMLReader [2]. I > >modified it > >> > >> > >to use gnu-regexp, since that's what XMLC uses for Regex > >and it also > >> > >> > >allows the class to be used in JDK's previous to 1.4. > >Anyway, that's > >> > >> > >the background. > >> > >> > > > >> > >> > >I've been trying to keep things in sync with your version, > >so I look > >> > >> > >at Rome's version every once in a while to see what's > changed. The > >> > >> > >last few changes have been fine. But this 1.14 change > seems odd to > >> > >> > >me (with at least one reasonably clear bug, explained > below). It > >> > >> > >provides for setting a static default encoding. > >Interestingly, I had > >> > >> > >noticed this lack of a user-defined-default deficiency > >early on. In > >> > >> > >XMLC's version, I added the ability to pass a custom > >default encoding > >> > >> > >into a couple of the constructors, with an internal > pre-set default > >> > >> > >of "UTF-8" if the default passed to the constructor is > >> > >> > >null. Effectively, this provides the same functionality > as you've > >> > >> > >added. However, the fact that XMLC's version provides > per-instance > >> > >> > >encoding defaulting makes it more flexible, as the > >preferred default > >> > >> > >value may change from use-to-use. Granted, this means more > >> > >> > >constructor arguments (for 2 constructors) and passing > around the > >> > >> > >values to the internal static methods, but the flexibility > is worth > >> > >> > >it and necessary in my use-case. > >> > >> > > > >> > >> > >I'm not telling you that you have to change because of my > needs. I > >> > >> > >will always use a separate copy because of my need to use > >gnu-regexp > >> > >> > >instead of JDK1.4 regex. But it makes life easier if the > >differences > >> > >> > >between XMLC's version and Rome's version are kept to a > >minimum so I > >> > >> > >can keep up with additions and bug fixes easily. I figure > if I can > >> > >> > >convince you to do it the way I've done it, it will make > my life > >> > >> > >easier and maybe, if you agree with the way I've > implemented it, > >> > >> > >benefit the Rome project at the same time. So, if you > could take a > >> > >> > >moment to review the latest version of XMLC's XMLReader > [2] and > >> > >> > >compare it against Rome's latest version, that would be > >great. I've > >> > >> > >made every attempt to keep white-space formatting in-line > >with Rome's > >> > >> > >version, so a simple diff should provide you with a clean > and clear > >> > >> > >look at the important differences between our versions. > >> > >> > > > >> > >> > > > >> > >> > >Additionally, it appears that you've introduced at least > one bug in > >> > >> > >the latest 1.14 version. Take a look at line #390. > >> > >> > > > >> > >> > >It currently is... > >> > >> > > encoding = (_defaultEncoding == null) ? UTF_8 : > >> > >> >_defaultEncoding; > >> > >> > > > >> > >> > >I think it should be.... > >> > >> > > encoding = bomEnc; > >> > >> > > > >> > >> > >You've already checked that "bomEnc" is equal to "UTF-8". > >Why would > >> > >> > >you then apply a default encoding rather than "bomEnc"? > >> > >> > > > >> > >> > > > >> > >> > >I have more of a question on line #425. Wouldn't > defaulting to > >> > >> > >"US-ASCII" be better than a static default, which would > more than > >> > >> > >likely be "UTF-8"? While XMLC's XMLReader uses the > >default encoding > >> > >> > >in most other applicable places, it leaves this one > alone. I'm not > >> > >> > >100% sure what the most appropriate choice is here, but I > >lean toward > >> > >> > >"XMLReader knows better than the user providing the > >default" in this > >> > >> > >case where I defer to the user in all other cases where I > need a > >> > >> > >default. I appreciate any advice you provide. > >> > >> > > > >> > >> > > > >> > >> > >There's also a possible pre-existing bug. Right after > line #502, > >> > >> > >shouldn't the bytes be unread just as they are on lines > #493, #498, > >> > >> > >and #506? I'm not sure about this one? I defer to your > expertise, > >> > >> > >but I thought I'd point it out just in case you just hadn't > >> noticed it. > >> > >> > > > >> > >> > > > >> > >> > >[1] http://forge.objectweb.org/projects/xmlc/ > >> > >> > >OR http://www.enhydra.org/tech/xmlc/ > >> > >> > >[2] > >> > >> > >> > > >http://cvs.xmlc.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc > >> > >> > >/modules/xmlc/src/org/enhydra/xml/io/XmlReader.java > >> > >> > > > >> > >> > > > >> > >> > >Jake > >> > >> > > > >> > >> > > >>--------------------------------------------------------------------- > >> > >> > >To unsubscribe, e-mail: users-unsubscribe@... > >> > >> > >For additional commands, e-mail: users-help@... > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > >--------------------------------------------------------------------- > >> > >> >To unsubscribe, e-mail: users-unsubscribe@... > >> > >> >For additional commands, e-mail: users-help@... > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> > --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: users-unsubscribe@... > >> > >> For additional commands, e-mail: users-help@... > >> > >> > >> > >> > >> > > > >> > > >--------------------------------------------------------------------- > >> > >To unsubscribe, e-mail: users-unsubscribe@... > >> > >For additional commands, e-mail: users-help@... > >> > > > >> > > > >> > > > >> > > > >> > > >> >--------------------------------------------------------------------- > >> >To unsubscribe, e-mail: users-unsubscribe@... > >> >For additional commands, e-mail: users-help@... > >> > > >> > > >> > > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscribe@... > >> For additional commands, e-mail: users-help@... > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: users-unsubscribe@... > >For additional commands, e-mail: users-help@... > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: XMLReader mods
by Alejandro Abdelnur-2
::
Rate this Message:
Jacob,
Finally I've made myself some time for this. I've just added a new constructor to XmlReader public XmlReader(InputStream is, boolean lenient, String defaultEncoding) I've also made the typo corrections you've indicated. Thanks. Alejandro On Sun, Apr 13, 2008 at 4:45 AM, Jacob Kjome <hoju@...> wrote: > I see you are looking for comments prior to a new release. So, will this > issue (see your - Alejandro - comment below) be addressed before a new > release? > > You can see the changes I've made to my own version, which is synced to the > 1.18 (latest) version of XMLReader in Rome... > > http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc/modules/xmlc/src/org/enhydra/xml/io/XmlReader.java > > > Jake > > Jacob Kjome wrote: >> >> At 02:43 AM 6/27/2007, you wrote: >> >MMhhh, let me see if I can refactor the constructors so you can reuse >> >the current one with content-type=NULL. >> > >> >> Any chance you will get around to this soon? >> >> Jake >> >> >On 6/24/07, Jacob Kjome <hoju@...> wrote: >> >> >> >> Hi Alejandro, >> >> >> >> I just took a look at the latest changes in XMLReader and noticed >> >> that you only added a new constructor for creating "a Reader using an >> >> InputStream and the associated content-type header", but not for >> >> creating "a Reader for a raw InputStream". For my purposes, I'd use >> >> the latter, except it doesn't exist. I added it to my own version, >> >> but figure that if it's useful to me it's probably useful to others >> >> and may as well be in the official version of XMLReader. Thoughts? >> >> >> >> BTW, you didn't add a javadoc "@param" entry for defaultEncoding and >> >> the javadoc for constructors taking a boolean "lenient" parameter >> >> probably shouldn't state that "this constructor is lenient regarding >> >> the encoding detection", since it depends on what the user passes to >> >> the constructor. There's also a few javadoc spelling errors, such as >> >> "an" instead of "and". No big deal, but I thought I'd mention it. >> >> >> >> All in all, great stuff! >> >> >> >> Jake >> >> >> >> At 12:27 AM 6/2/2007, you wrote: >> >> > >> >> >Thanks for addressing the issues and for the explanations! >> >> > >> >> >Jake >> >> > >> >> >At 09:47 AM 6/1/2007, you wrote: >> >> > >Jacob, >> >> > > >> >> > >This got lost in my inbox, while working on the XmlReader I ran >> across >> >> > >it. Sorry for the delay. >> >> > > >> >> > >On your comment on line #390, you are right it should be bomEnc. >> >> > > >> >> > >On your comment on line #425, is US_ASCII (HTTP content type >> declares >> >> > >a MIME of text type and XML sub-type. There is not HTTP >> Content-type >> >> > >charset encoding information. The charset encoding is US-ASCII. >> Refer >> >> > >to RFC 3023 Section 3.1. Text/xml Registration.) >> >> > > >> >> > >On having default encoding per instance, keeping backwards >> >> > >compatibility we can add a constructor that takes an instance >> default >> >> > >encoding. All other constructors would use the static default >> >> > >encoding. >> >> > > >> >> > >A >> >> > > >> >> > > >> >> > >On 5/16/07, Jacob Kjome <hoju@...> wrote: >> >> > >> >> >> > >> Maybe the 3rd time's the charm? I saw there was an update to >> >> > >> XMLReader so I thought I'd remind Rome developers of my 1.14 >> >> > >> findings. They are still entirely relevant. Please pay special >> >> > >> attention to the possible bugs I pointed out. I would hope >> you'd be >> >> > >> interested in them. If you think I'm out to lunch, please say >> >> > >> so. Otherwise, I think these are things that ought to be >> addressed >> >> > >> rather than ignored. You can read below or view the whole >> thread in >> >> > >> the archives.... >> >> > >> >> >> > >> >> https://rome.dev.java.net/servlets/ReadMsg?listName=users&msgNo=1251 >> >> > >> >> >> > >> >> >> > >> Jake >> >> > >> >> >> > >> At 01:20 AM 3/9/2007, you wrote: >> >> > >> > >> >> > >> >Now that there's a bit more activity on the Rome list, any >> comments >> >> > >> >on my email from a few weeks ago? See below... >> >> > >> > >> >> > >> >Jake >> >> > >> > >> >> > >> >At 07:16 PM 2/17/2007, you wrote: >> >> > >> > > >> >> > >> > >I tried sending this directly to the Rome developers a >> couple weeks >> >> > >> > >ago, but received no response. So, I finally signed up for >> a >> >> > >> > >dev.java.net account to see if I would get a response on >> >the official >> >> > >> > >list. Here's what I wrote..... >> >> > >> > > >> >> > >> > > >> >> > >> > >My name is Jacob Kjome and I'm the maintainer of the XMLC >> >project [1] >> >> > >> > >where we use a modified version of your XMLReader [2]. I >> >modified it >> >> > >> > >to use gnu-regexp, since that's what XMLC uses for Regex >> >and it also >> >> > >> > >allows the class to be used in JDK's previous to 1.4. >> >Anyway, that's >> >> > >> > >the background. >> >> > >> > > >> >> > >> > >I've been trying to keep things in sync with your version, >> >so I look >> >> > >> > >at Rome's version every once in a while to see what's >> changed. The >> >> > >> > >last few changes have been fine. But this 1.14 change seems >> odd to >> >> > >> > >me (with at least one reasonably clear bug, explained >> below). It >> >> > >> > >provides for setting a static default encoding. >> >Interestingly, I had >> >> > >> > >noticed this lack of a user-defined-default deficiency >> >early on. In >> >> > >> > >XMLC's version, I added the ability to pass a custom >> >default encoding >> >> > >> > >into a couple of the constructors, with an internal pre-set >> default >> >> > >> > >of "UTF-8" if the default passed to the constructor is >> >> > >> > >null. Effectively, this provides the same functionality as >> you've >> >> > >> > >added. However, the fact that XMLC's version provides >> per-instance >> >> > >> > >encoding defaulting makes it more flexible, as the >> >preferred default >> >> > >> > >value may change from use-to-use. Granted, this means more >> >> > >> > >constructor arguments (for 2 constructors) and passing >> around the >> >> > >> > >values to the internal static methods, but the flexibility >> is worth >> >> > >> > >it and necessary in my use-case. >> >> > >> > > >> >> > >> > >I'm not telling you that you have to change because of my >> needs. I >> >> > >> > >will always use a separate copy because of my need to use >> >gnu-regexp >> >> > >> > >instead of JDK1.4 regex. But it makes life easier if the >> >differences >> >> > >> > >between XMLC's version and Rome's version are kept to a >> >minimum so I >> >> > >> > >can keep up with additions and bug fixes easily. I figure >> if I can >> >> > >> > >convince you to do it the way I've done it, it will make my >> life >> >> > >> > >easier and maybe, if you agree with the way I've implemented >> it, >> >> > >> > >benefit the Rome project at the same time. So, if you could >> take a >> >> > >> > >moment to review the latest version of XMLC's XMLReader [2] >> and >> >> > >> > >compare it against Rome's latest version, that would be >> >great. I've >> >> > >> > >made every attempt to keep white-space formatting in-line >> >with Rome's >> >> > >> > >version, so a simple diff should provide you with a clean >> and clear >> >> > >> > >look at the important differences between our versions. >> >> > >> > > >> >> > >> > > >> >> > >> > >Additionally, it appears that you've introduced at least one >> bug in >> >> > >> > >the latest 1.14 version. Take a look at line #390. >> >> > >> > > >> >> > >> > >It currently is... >> >> > >> > > encoding = (_defaultEncoding == null) ? UTF_8 : >> >> > >> >_defaultEncoding; >> >> > >> > > >> >> > >> > >I think it should be.... >> >> > >> > > encoding = bomEnc; >> >> > >> > > >> >> > >> > >You've already checked that "bomEnc" is equal to "UTF-8". >> >Why would >> >> > >> > >you then apply a default encoding rather than "bomEnc"? >> >> > >> > > >> >> > >> > > >> >> > >> > >I have more of a question on line #425. Wouldn't defaulting >> to >> >> > >> > >"US-ASCII" be better than a static default, which would more >> than >> >> > >> > >likely be "UTF-8"? While XMLC's XMLReader uses the >> >default encoding >> >> > >> > >in most other applicable places, it leaves this one alone. >> I'm not >> >> > >> > >100% sure what the most appropriate choice is here, but I >> >lean toward >> >> > >> > >"XMLReader knows better than the user providing the >> >default" in this >> >> > >> > >case where I defer to the user in all other cases where I >> need a >> >> > >> > >default. I appreciate any advice you provide. >> >> > >> > > >> >> > >> > > >> >> > >> > >There's also a possible pre-existing bug. Right after line >> #502, >> >> > >> > >shouldn't the bytes be unread just as they are on lines >> #493, #498, >> >> > >> > >and #506? I'm not sure about this one? I defer to your >> expertise, >> >> > >> > >but I thought I'd point it out just in case you just hadn't >> >> noticed it. >> >> > >> > > >> >> > >> > > >> >> > >> > >[1] http://forge.objectweb.org/projects/xmlc/ >> >> > >> > >OR http://www.enhydra.org/tech/xmlc/ >> >> > >> > >[2] >> >> > >> >> >> > >> >http://cvs.xmlc.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/xmlc/xmlc >> >> > >> > >/modules/xmlc/src/org/enhydra/xml/io/XmlReader.java >> >> > >> > > >> >> > >> > > >> >> > >> > >Jake >> >> > >> > > >> >> > >> > >> >>--------------------------------------------------------------------- >> >> > >> > >To unsubscribe, e-mail: users-unsubscribe@... >> >> > >> > >For additional commands, e-mail: >> users-help@... >> >> > >> > > >> >> > >> > > >> >> > >> > > >> >> > >> > > >> >> > >> > >> >> > >> >> >--------------------------------------------------------------------- >> >> > >> >To unsubscribe, e-mail: users-unsubscribe@... >> >> > >> >For additional commands, e-mail: users-help@... >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> >> >> > >> >> --------------------------------------------------------------------- >> >> > >> To unsubscribe, e-mail: users-unsubscribe@... >> >> > >> For additional commands, e-mail: users-help@... >> >> > >> >> >> > >> >> >> > > >> >> > >> >--------------------------------------------------------------------- >> >> > >To unsubscribe, e-mail: |
