RE: parseType="literal"

>
>   One expected that the parser doesn't modify the literal. If I
> add a valid
> XML, I expect to get the same String when I read it (at least the same
> XML). Why rdf parser should modifiy it? What's the use of this literal in
> RDF? I just wanted to keep it as information (we will use CDATA by now).
>
>   The problem it's when I serialize the object and read the serialization,
> it doesn't work because of the changes (for instance two namespaces with
> the same name inside the same element window,

Yes that is a mistake, I need to fix it.

Marc, why don't you fix it and mail me the patch?

While you're about it, you could do the processing instruction event as
well. Then your example would work correctly. If you're interested I could
give you more detail about what  would be needed for that. (You could also
include XML Comments, if they are part of the literal).

> doesn't work)
>

Hmmm ....

Consider the MathML example in M&S

http://lists.w3.org/Archives/Public/www-archive/2001Jun/att-0021/00-part#257


The literal needs to retain the default namespace, because otherwise it is
no longer MathML markup. This in essence is the namespaces issue being
considered by RDF core:

http://www.w3.org/2000/03/rdf-tracking/#rdfms-xml-literal-namespaces

Consider a literal with an entity reference in it.
The entity reference (IMO) should be expanded (and, if necessary, reescaped)
because otherwise it is left dangling.

In my view, an RDF/XML file can be passed through an XSLT preprocess of one
sort or another. This reflects a key clarification of the WG that RDF/XML is
defined over XML not over text. Hence, some aspects of the xml literal, as
in the file, are truely not accessible from an xml literal within RDF.

The question is "which parts?"
My prefered answer is something like those parts that are not accessible
within XSLT.

I went down this path over the weekend, the results of my musings are on the
core list (not yet publicly visible - seems to be a W3C server problem).

Jeremy

Received on Monday, 11 March 2002 06:56:52 UTC