A couple of folks have submitted C++ compilation and linking tasks to the
Ant project (http://jakarta.apache.org/ant/index.html) and a small group has
commandeered the ant-contrib SourceForge project to create a hybrid
implementations with the goal of eventual inclusion in Ant.
I was thinking
The Xerces-dev list is inactive, there are now specific mailing lists for
Xerces-C and Xerces-J development and for Xerces-J users. Your question does
not appear to be related to Xerces at all,
however. As I understand it, you have a class name in a string and you want to
create an instance
Sandy Gao is working on a redesign of schema caching for Xerces-J and expects to be
visible pretty soon. When that design gets critiqued and functional in Xerces-J, then
it could be incorporated in
Xerces-C.
-
To unsubscribe,
Xerces-com.dll requires the appropriate xerces*.dll to be either in the same directory
or on the path when registered and when accessed. It also has unnecessary
dependencies on wininet.dll and
urlmon.dll which are provided by IE 4.0 and later. The other dependencies are
standard system DLL's
Sorry, some more *nix novice questions.
If trying to get Xerces in the distributions is primarily to allow already compiled
code to run without having to provide the .so's, would an binary/runtime drop that did
not have header files resolve
the collision issue? People who wanted to rebuild
Just a fuzzy second thought on Friday afternoon .. don't
yell if you don't like it . :-)
I had the same thought this morning, but wasn't sure enough about it to float it. You
are a braver man than I.
The root directory could be just src/xercesc. However, you would have to
No, I have said several times that this will not require any
existing apps to change the way that they #include the
Xerces-C++ headers. Read the thread.
Actually, I had read every message in the thread before posting. I had not been
following the thread but started to see things that
That behavior is explicitly prescribed by the XML Recommendation
http://www.w3.org/TR/REC-xml#sec-line-ends for all XML processors to maximum
interoperability in the face of different line-ending
conventions.
I do not believe there is a way to disable conformance with this required behavior
Do you have the Microsoft Platform SDK in your include path? The definitions of the
MSXML 2 interfaces are not included in Visual C++ 6. See
http://xml.apache.org/xerces-c/build-misc.html#faq-2 for
details.
-
To unsubscribe,
You've got the Old Testament in XML and you want the COM wrapper too?
It should be, but at the time that Xerces-COM was been actively developed, the build
developer didn't either have the time or was concerned about disrupting the normal
Xerces-C build and so it never
got added to the
There is not a clean way to do it in the current
code base that would mimic
DOM_Entity entity = (DOM_Entity) node;
in Java. To do this, we would need an
DOMNode::operator DOM_Entity() that
would throw an exception if the node
type was inappropriate.
The best you can do, is to check the node
Might be a little cleaner just to create a derived class of Grammar
and to always respond to getEntityDecl (or a similar
name) which gets called when the scanner encounters an non-character
entity.
The association of Grammar's with Documents will need to get
rethought during the Schema push. So
If you C string is coming in as ISO-8859-1 whose characters have the same value in
Unicode,
something like the follow should work:
void copyToDOMString(const char* iso8859String, DOMString str) {
const int BUFSIZ = 1024;
XMLCh buf[BUFSIZ+1];
const char* currentSrc = iso8859String;
XMLCh*
The Xerces-C parser builds a DLL (on Windows) that
contains an event based parser that supports the
SAX and SAX2 interfaces along with a DOM implementation.
There is not a separate code base for the SAX parser
and the DOM implementation and there are not separate
code bases for Windows vs other
Not having ever looked into ICU, would it be appropriate to add equivalent
functions for UTF-16 to and from ISO-8859-1 in char*
(throwing exceptions or a failure code when the source contained
characters out of the range).
In my personal DOM implementation, a DOMString
that only contains
That wouldn't work. I assume you meant = 255, but anyway, it
still probably
wouldn't work. Just because 8859-1 can *hold* any one byte
encoding, the
meaning of those code points would be lost. You would have to
use something
like UTF-8, i.e. something that is a transfer encoding and
That is a fairly huge topic and not specific to Xerces-C. I would
recommend Unicode: A Primer by Tony Graham when you are ready to get
into all the gore.
For an quick overview, XML.com had a article last year:
http://www.xml.com/pub/a/2000/04/26/encodings/index.html
I submitted several months ago a small series of patches
(http://marc.theaimsgroup.com/?l=xerces-c-devm=97996829301593w=2)
, that would have provided a clean way to deallocate the memory that would
not have been affected by differing RTL's and would allow you to
do transcoding to the stack if
I've been laying the groundwork for taking a shot at completing
Andy Heninger's "new" DOM for Xerces-C++ and supporting
DOM 2 events. Since there has been
a lot of discussion about the DOM recently, I thought that I would
let you know my intentions and current thoughts. I need this for
my own
If it is big or too complicated to put into one message,
then put it on a web site somewhere and post a URL here.
It is very hard to know what you are proposing from
your description. Maybe it is a reaction to the
extremely verbose samples that come with Xerces-C,
the code can be greatly
My gut feeling (since I don't have an AIX machine) is that the signatures don't match
due to two different definitions of bool.
If you are getting a multiple definition warning for bool in XercesDefs.hpp, then
NO_NATIVE_BOOL processor macro must be defined. If your platform actually has a
Dean Roddey wrote:
I originally did the UTF-8 transcoder that way, with a leading loop.
However, it was removed at some point because it caused a
problem I think. I
don't remember what it was, but it must have been removed for
a reason,
because I'd already proven that it was a lot faster.
Has anything been done with Andy Heninger's new DOM since his message on 1 March (see
http://www.apache.org/~andyh/).
By the way, will the mailing list archives ever been extended into 2001?
-
To unsubscribe, e-mail: [EMAIL
The solution 1 (cast operator):
class DOM_Node
{
...
operator DOM_Element(void);
};
The solution 2 (cast constructor):
class DOM_Element
{
...
DOM_Element (const DOM_Node);
};
I think I would prefer the cast operator since that would most cleanly mimic the
Your source document is probably in ISO-8859-1 and without a XML declaration it
is assumed to be in UTF-8 per the XML spec.
You could either add an XML declaration to your source document:
?xml encoding=ISO-8859-1?
or use a character entity, #nnn; where nnn is the unicode code point for the
Steven Coffman wrote:
If SVG is going to be DOM based, rather than treated as a special case form
of XSL:FO, then that immediately says, Xerces to me. Should an
implementation of the W3C's SVG DOM be part of Xerces? Does that allow us to
do anything cool? Should it continue to be part of FOP? If
Dean wrote:
I would be a little leary of believing those numbers too much. Perhaps the
particular test you ran might have skewed the results a little towards that
particular code, but we've run extensive tests here with some pretty
powerful tools and they don't show up that code as being very
Some background:
I've been lobbying the XML Schema working group to reestablish the real
datatype that had been in Datatypes until the 17 Dec 1999 draft. Prior to the
17 Dec draft, there had been a real datatype
that was a arbitrary range and precision floating point value. There was a
.), and
accessors for them.
Mike
Arnold, Curt wrote:
Some background:
I've been lobbying the XML Schema working group to reestablish the real
datatype that had been in Datatypes until the 17 Dec 1999 draft. Prior to
the 17 Dec draft, there had been a real
datatype
that was a arbitrary range
First of all this is the wrong forum for generic XML usage questions. This
list is people working on the development of the Xerces parser and should not
be addressing either Xerces usage questions or
generic XML questions. I'd recommend that you use the comp.text.xml newsgroup
though there
I'm definitely in favor of using erase() (to clear) and empty() (to check for
zero length string) and against a static null string. I've converted all of
the = nulls and string == null's in a
previous personal variant and it wasn't all that bad. I think it is one to
just to bite the bullet
That was another thing that I had to fix up in the STL semantics code that I
sent you. If I remember right (I'm away from my development machine right
now), that NodeImpl took as its last argument an
DOMString optional argument with a NULL default value. There was only one
constructor that
Why aren't the values for FilterAction: FILTER_ACCEPT, FILTER_REJECT and
FILTER_SKIP? That would be consistent with your treatment of ShowType.
I think that I had to fix all of these in my lets try basic_string
semantics experiment by using array initialization. I can send you that
code and you can mine it just for replacement of the the const char*
constructors.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Dean Roddey wrote:
We cannot use any sort of global object destruction to clean them up, ...
I'm really curious to know what the issues are driving avoidance of global
objects for static resources. Is it a platform issue, the indeterminent
order, or something else?
Dean Roddey wrote:
For use, its mainly the inderminant order or creation and destruction.
There is no good way, that is portable, to make sure that things get
created and cleaned up in the right order. This is particularly sticky in
the case of the objects that were in question in this topic, e.g.
I had overlooked those sections. It definitely makes comparision precise.
I don't think it is acceptible for an application to not be able to
distinguish 30D from 1M since legally they are different things. Hopefully,
you could parse out the months and years separately from the precise
durations
Dean wrote:
I would be against any tying of the validator to the DOM. This would be
against the clean layering of the system. Also, you are assuming that DOM
would be the only place in which such stuff might be stored for later
validation, which is probably not true. It may just be that either
comparson? Should you be using recurringInstant instead of timeDuration?
george
-Original Message-
From: Arnold, Curt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 19, 2000 11:13 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Proposal for Xerces-J Schema validators for timeInstant
XML Schema Part 2, Section 3.2.7.1, last paragraph:
Time periods, i.e. specific durations of time, can be represented by
supplying
two items of information: a start instant and a duration or a start instant
and
an end instant or an end instant and a duration
-
Actually, I interpreted
You definitely do not want to normalize the bound expressed in the schema on
every validation. However, that should only require that the objects used
for the min and max bounds contain the normalized object. Also, you want to
normalize the string value once during the processing of the facets.
Does the DOMString(=\) approach work on all platforms. If so, then on
the platforms that L doesn't work on, you could define _XSTR(str) as
DOMString(str). It just seemed like a lot of unnecessary effort on most
platforms.
Okay, my head is spinning now. What started this whole thing was an
observation that AttrImpl (possibly among others) was transcoding and doing
unnecessary (unnecessary on most platforms at least) constructors for string
literals.
The best solution for within Xerces, is to avoid string literals
Sorry, I remember the discussion and I really didn't mean wstring, it just
slipped out.
-Original Message-
From: Andy Heninger [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 13, 2000 12:04 PM
To: [EMAIL PROTECTED]
Subject: Re: xalan-c Problem with Xerces initialization
Curt Arnold
The DOMString(int) constructor is used in at least AttrImpl::getValue().
I agree it should be changed, I'd recommend replacing its functionality with
a reserve(int) method ala std::basic_string.reserve().
---
I also ran into some curious code in this routine.
DOMString
I would recommend that when someone starts working on implementing min/max
validation of integers and reals that we attempt to implement the comparision
operation without converting the string into a
primitive numeric type. This would avoid problems with the C RTL has not been
initialized and
Dean Roddey wrote:
3) Very importantly, things like LSomeWideString will be directly
passable to parser APIs (as long as your compiler generates Unicode code
points for L prefixed constants.)
Just as an aside, it would be useful to define something like the _TSTR macro
in Win32, say
#define
The ICU libraries were incorrectly included in linker options for some
configurations (I believe the Intel Win32 Release) for the first source drop
of VC6, but wasn't actually used in the code. Removing the libraries from
the linker options allowed the DLL to build without the ICU libraries
The right way to do this under Windows is to put a thin (non-Automation,
in-process only) COM interface around ICU and support registration with
DllRegisterServer. In Xerces, call CoCreateInstance (or similar call) when
the DLL needs to be loaded and have the stub implementation in Xerces call
it that way...I'm not sure about this,
though...Do you think they should retain the environment variable
(ICU_DATA) way, too?
Mike
Arnold, Curt wrote:
The right way to do this under Windows is to put a thin (non-Automation,
in-process only) COM interface around ICU and support registration
I don't have a .dsp, but a .dsw (in my build from the first binary drop)
which seems to open properly in VC6 (SP2) with all the sub projects,
DOMCount, etc. What happens if you try to load the .dsw (if you have one)?
-Original Message-
From: Michael Mason [mailto:[EMAIL PROTECTED]
Sent:
I ran into a problem using the very first xerces source drop on Win32. It
may be fixed now and indicates that I should get familiar with CVS et al,
but if someone who is more intimate with the tools could check on this, I'd
appreciate it.
In \src\util\Compilers\VCPPDefs.hpp
const char* const
David_N_Bertoni@lotus.com [mailto:[EMAIL PROTECTED] Wrote:
The meta issue here is that I think this is a very confusing
implementation
for C++ programmers -- most would think that a DOMString is more like the
typical C++ string class (std::string, for example), rather than a Java
StringBuffer. I
I previously wrote:
I assume this should be
const char* const XML4C_DLLName = xerces-c_1_0 XML4C_DLLVersionStr;
Apparently it should have been
const char* const XML4C_DLLName = xerces-c XML4C_DLLVersionStr;
54 matches
Mail list logo
