ese issues.
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
Curt Arnold <[EMAIL PROTECTED]> on 12/21/99 09:48:14 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: PROPOSAL: DOMString
I think it is valuable to re
I think it is valuable to remain abstract in DOMString
since we may want to allow specific optimizations that
are not appropriate in a generic basic_string.
However, it might be possible to morph DOMString so
that it has identical semantics to a subset of
basic_string and could either be implement
>[JBDP] I don't know how many people have compilers and libraries
(including
>legacy libraries, whether home-grown or thirds party) that support
>character-style and string-style operations on unsigned shorts so I don't
>know how "few" the people are who will be inconvenienced.
It is our belie
Tim Bray wrote:
> I'm with Mr. Roddey. At this point in history, doing extra work or adding
>
> extra complexity in order to empower people to dodge internationalization
> is just not defensible on business, engineering, or ethical grounds. -Tim
[JBDP] Well I kind of agree on the moral front: I
[JBDP] In reply to Dean Roddy:
> I would like to go on the record as saying that I'm very much against
> this
> proposal, nothing personal.
[JBDP] Fair enough.
> I believe that the simplicity and maintainability of the current
> architecture is more important. The work to make the parser core
>
g could still end up being far less onerous a task.
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 12/20/99 03:43:27 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: PROPOSAL: DOMStr
I disagree. By having separate interfaces for strings for DOM and SAX, we
run into all sorts of performance hits. For example, in Xalan, we have a
DOM that we want to serialize. We have classes like FormatterToHTML and
FormatterToXML, all derived from SAX's DocumentHandler. Methods in the
Docu
[EMAIL PROTECTED] on 12/20/99 01:36:55 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: PROPOSAL: DOMString
Of course, you do what you need to do for the parser's internal
representation. But at the API level, where people deal with DOM and SAX,
the
Of course, you do what you need to do for the parser's internal
representation. But at the API level, where people deal with DOM and SAX,
then we have more constraints. The W3C DOM recommendation mandates that
DOMString's are strings in UTF-16 encodings. So, strictly speaking, the
parser's DOM
uff for the DOM string representation.
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 12/20/99 12:03:08 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: PROP
As I see it, there are two reasons why you might need to transcode.
First, you might need it to access some particular algorithm you need. You
have some nice tokenizer class, or a regular expression class that takes
char *. Instead of rewriting the class to take XMLCh*, you transcode,
process a
At 11:55 AM 12/20/99 -0700, [EMAIL PROTECTED] wrote:
>I would like to go on the record as saying that I'm very much against this
>proposal, nothing personal.
I'm with Mr. Roddey. At this point in history, doing extra work or adding
extra complexity in order to empower people to dodge internation
<[EMAIL PROTECTED]> on 12/20/99 10:26:37 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: PROPOSAL: DOMString
On Monday, December 13, 1999 at 8:17 PM [EMAIL PROTECTED] wrote:
<<>>
I'd be very
On Monday, December 13, 1999 at 8:17 PM [EMAIL PROTECTED] wrote:
<<>>
I'd be very keen to see an option to allow XMLCh to be equated to char. We
currently have minimal interest in supporting anything other than ASCII.
Storing non-ASCII characters using Java-style NUL-free UTF8 would be a
simple w
+1 for
typedef std::basic_string DOMString;
-joe
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 13, 1999 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: PROPOSAL: DOMString
>
>
>
> How about we ty
How about we typedef XMLCh in the platform-specific header files and then
typedef DOMString to be std::basic_string. The DOM spec is pretty
specific about these being 16-bit characters, so this would ensure it by
default.
And if someone wants to change the typedefs and recompile, they could
crea
Regarding DOMSTring, Joe Gregorio wrote:
>1. Don't change anything (except maybe add a larger red flag
> in the documentation).
>2. Change DOMString to have value semantics.
>3. Drop DOMString in favor of wstring.
>
>Personally, I would prefer 3, but 2 is probably
>the most reasonable
I like option #3. Perhaps even make it so you can flip a switch and
recompile to work with a plain std::string (8-bit chars). If you know that
your documents will all be ASCII, this could be a big memory savings.
But what is it about the current state of the standard libraries that would
be li
18 matches
Mail list logo
