RE: DOMString (was: xalan-c Problem with Xerces initialization)

[roddey]

>But, this causes DOMStrL to evaluate to different types on different
>platforms.  DOMStringL("hello world") could be either a const wchar_t* or
a
>DOMString.  This sets off warning bells in my head.
>

I thought you just were looking for a solution to the scenario you showed
earlier where the code was building up temp strings, by appending short
char strings. For that, what I suggested will work. But, I didn't question
why you were doing that. So yes, if you can stand doing the arrays of
Unicode characters, instead of L"" type strings, that avoids the whole
problem.


>I guess the meta-question is this: do we want a solution that encompasses
>SAX and XMLCh*, or just DOM and DOMString?  It seems that the differences
>in the representation of L"foo" is going to effect SAX as well.  And Xalan
>uses both

I'm not sure that there is a problem here. SAX is just a layer on the
parser that just spits stuff out. Its always spit out in XMLCh format, and
was always that way since it was internalized down in the guts of the
parser.

Or, are you saying that you guys are also spitting stuff out a SAX
interface?

----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]