There are two reasons really.
1) If we use it, then very place where the product is used must support it.
else they have to cut that code out ever time they want to port a new drop.
For instance, the obvious thing to do would be to use std::wcout, but what
if that's not available on the PDA you want to use or on the ancient
compiler your political situation forces you to use?
2) What if you are using some other library platform? You'll pay whatever
cost there is involved in us linking in more code that you don't use, and
you'll still have to write something yourself because your library has its
own streams.
Probably, in the end, having some optional layered libraries over the core
might be the appropriate direction. We could add another DLL/SharedLib
which makes full use of the standard libs. If you don't want or cannot
support that, then just drop that separate project out of your build of the
system. But we'd really want to keep it cleanly separated to make doing
that a non-brainer (like a single build switch or some such thing.)
Certainly, if people want to post their solutions to the problem here for
others to benefit from, have at it. I guess that's partly what this forum
is for?
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Peter H. Smith" <[EMAIL PROTECTED]> on 01/28/2000 05:30:32 AM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces-writing xml
Are you avoiding tying to a streaming implementation
because:
1. streaming is bad or unncessary?
2. it's not clear what the best implementation is?
3. there is vendor politics involved?
I'm asking this openly because I'm new to this and
don't know the answer. If the answer is 1, I'd love
to learn more about the right way to do things. If
the answer is 2, has anyone written up some comparisons
that you could point me to to learn more?
If the answer is 3, how about creating an "unofficial"
area where people can check in their favorite extensions
along with some explanation of why they think they are
good. For example, it might help people to see ten or
so hacks to DOMPrint; they could see how it is done and
maybe pick up one that's 60% what they want. It would
also help to see someone else's alternative to DOMPrint
if there is one. Ideally there'd be an unmoderated
ratings and review system, sorta like AlphaWorks, so
people could dis ideas that are just plain bad and
praise ideas that have merit.
> Dean Roddey wrote:
>
> The 'writing part' might be a little misleading. We don't have any canned
> formatter for outputting the XML. There are a number of reasons for this.
> Partly its because we don't want to tie our code to any particular
> streaming implementation. And, partly its because there are a lot of
> different requirements for how XML is output. But, you can pretty easily
> rip off the code in the DOMPrint example to dump out a DOM tree.
>
> Bernd Schwonkel wrote:
> ...
> May be you can give me a tip were I can get an
> example or some hints using Xerces for writing.
