On 10/26/06, Simon Laws <[EMAIL PROTECTED]> wrote:
This is primarily a C++ question but I guess could apply to Java also. I'm
trying to read a document into C++ SDO that contains a CDATA section. The
corresponding CDATA doesn't make its way into the resulting SDO. I put the
C++ SDO implementation in the debugger and found the reason why:
sax2parser.cpp
void sdo_cdataBlock(void *ctx, const xmlChar *value, int len)
{
}
So the callback exists, gets called with the correct data during the
parse, i.e. LibXML2 is doing the right thing, but the callback is ignored.
Is there a good reason for this? I did a quick search of the C++ and Java
specs and they don't appear to discuss CDATA specifically. Can someone
comment on whether the Java implementation handles CDATA successfully?
Logically, from an SDO point of view, there is probably no need to treat
CDATA specially as the SDO model dictates precisely the difference between
data and structure. We may find that to make the XML DAS function work we
have to know that a property potentially contains markup but I'd have to
look closely at how the C++ SDO implementation of the XML DAS function
streams out SDOs to XML when requested to do so.
If CDATA hasn't been omitted for a good reason I'll come up with a
proposal for C++ SDO.
Regards
Simon
I didn't get any response to this. Here are my further thoughts..
There are a number of options for representing CDATA in SDO, for example
1) Duplicate the CDATA string as is, including the "<![CDATA[" and "]]>"
markers, to the appropriate property in the data object hiearchy
2) Duplicate the CDATA string excluding the "<![CDATA[" and "]]>" markers
and instigate a special flag to indicate that CDATA is present.
CDATA is the specific concern of XML, i.e. the chracter entities that CDATA
protects an XML parser from are of no
concern to SDO because SDO is not intended to be tied directly to XML. So
given the example options above we
either expose the specifics of XML to the SDO core 2) or to the SDO user 1).
Neither are particularly attractive.
1) appears to be the simplest approach to implement because it provides a
mechanism for the user to read, and
create CDATA without having to provide much special support in SDO. 2) is
more involved particularly because
CDATA can appear mixed in with other text strings and so a sequence may need
to be used to represent properties
that have a mixture of text and CDATA marking those sequences entries that
are CDATA.
1) does require changes (at least in C++ SDO) because XML parsers tend to be
too helpful in this case for
processing CDATA. XML parsers, libxml2 in particular, recognize the
"<![CDATA[" and "]]>" sequence as a special
indicator and throw it away returning just the text it includes. We would
have to reintroduce it and store it in
the parameter value in question. The C++ SDO implementation uses a lot of
XML string handling before the parameter
value is actually stored which URL encodes parts of the CDATA markers so
this would have to be fixed. When writing out the CDATA strings any string
typed properties would have to be scanned for the markers so that the
appropriate libxml2 functions can be called to get the CDATA sections in the
right place.
I have a test implementation of 1). If this is the way we want to go I would
have to do more work to thread CDATA handling through the xml strings that
are used to set parameters. Happy to do this but would like to discuss
first.
Thoughts (particularly on what Java SDO does with CDATA)?
Simon
