cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

xml attribute of type CDATA

ptc-957266
1-Newbie

xml attribute of type CDATA

Hello,

I have a document with attributes of type CDATA (validated by an XML
DTD).
If in that attribute, I have a value like "a&b", I don't get an error in
Epic.

I have tested this in several applications:
- OmniMark
- Altova XMLSpy
- Eclipse
- xmlvalid

They all give an error (something like "Fatal error: entity reference
not terminated correctly. Expected ';").

So my value should be code like: a&b
Why does Epic doesn't give an error?


I red that:
"Note that attribute value literals are always parsed as replaceable
character data, regardless of the attribute's declared value. This means
that references (&xxx;, &#yyy;) are recognized and replaced in attribute
specifications, even for CDATA attributes."
(
7 REPLIES 7

Michael,

Change the ampersand from the character to the appropriate entity and the error should go away.

One of the hidden rules of both SGML and XML. Entity open characters are read by the parser as such, even in an attribute.

Lynn


---- Vanhoutte Michiel <michiel.vanhoutte@wkb.be> wrote:
> Hello,
>
> I have a document with attributes of type CDATA (validated by an XML
> DTD).
> If in that attribute, I have a value like "a&b", I don't get an error in
> Epic.
>
> I have tested this in several applications:
> - OmniMark
> - Altova XMLSpy
> - Eclipse
> - xmlvalid
>
> They all give an error (something like "Fatal error: entity reference
> not terminated correctly. Expected ';").
>
> So my value should be code like: a&b
> Why does Epic doesn't give an error?
>
>
> I red that:
> "Note that attribute value literals are always parsed as replaceable
> character data, regardless of the attribute's declared value. This means
> that references (&xxx;, &#yyy;) are recognized and replaced in attribute
> specifications, even for CDATA attributes."
> (

Going on to read the entire message, hey it's just barely 6 AM. Epic may have converted the ampersand to the entity when you typed it in. Take a look at the file in an ASCII editor.

I know that Epic will give the error if you do manage to get the entity open in the attribute.

Lynn
---- Vanhoutte Michiel <michiel.vanhoutte@wkb.be> wrote:
> Hello,
>
> I have a document with attributes of type CDATA (validated by an XML
> DTD).
> If in that attribute, I have a value like "a&b", I don't get an error in
> Epic.
>
> I have tested this in several applications:
> - OmniMark
> - Altova XMLSpy
> - Eclipse
> - xmlvalid
>
> They all give an error (something like "Fatal error: entity reference
> not terminated correctly. Expected ';").
>
> So my value should be code like: a&b
> Why does Epic doesn't give an error?
>
>
> I red that:
> "Note that attribute value literals are always parsed as replaceable
> character data, regardless of the attribute's declared value. This means
> that references (&xxx;, &#yyy;) are recognized and replaced in attribute
> specifications, even for CDATA attributes."
> (

I didn't type it in Epic.
I opened it in Epic: no error.
I saved it in Epic, looked in an ASCII editor: no changes to the value.
I opened it again in Epic: no error given.

Can somebody try to do the same?

Regards,
Michiel

Michiel,

Not I.

I added this to a test document. with an ASCII editor.

<xref pretext="test" of=" &p=" in=" cdata&quot;="/>

When I opened the file in Epic, I got the following error.

*** Error on line 66 in file F:\epicuser\mwo\mwo_test.xml:
[A30087] Syntax error. Expecting entity close ';'.
The last text seen was "&P"

I then added another attribute to the element. in Epic.

<xref posttext="test" of=" &a=" in=" cdata=" in=" epic&quot;=" pretext="test" of=" &p=" in=" cdata&quot;="/>

I saved the file and reopened it in Epic. No error. Copying the element and pasting into an ASCII editor I see this

<xref posttext="test" of=" &a=" in=" cdata=" in=" epic&quot;<br="/>pretext="test of &P in cdata"/>

So it looks like during the save, Epic is changing the character to the entity. This is dependent on how you set you save values (at least for most entities, reserved, like an entity open, may be changed by default)

Lynn
---- Vanhoutte Michiel <michiel.vanhoutte@wkb.be> wrote:
> I didn't type it in Epic.
> I opened it in Epic: no error.
> I saved it in Epic, looked in an ASCII editor: no changes to the value.
> I opened it again in Epic: no error given.
>
> Can somebody try to do the same?
>
> Regards,
> Michiel
>

Apparently this is a Epic 4.3 problem.

I tested this now in a test version of Epic 5.1 and I indeed get an
error:
Syntax error. Expecting entity close ';'.
The last text seen was "&b".

When saving the document then in Epic 5.1 the ampersand charachter is
escaped.
No errors any more.

Regards,
Michiel

We had some issues with Epic 5.2 with entities being automatically
converted. If I remember correctly the settings to look at are :
charentdisplay (on)
and
entityinputconvert (off).

Robert G. Paisley
Northrop-Gruumman
"Experience is that marvelous thing that enables you to recognize a
mistake when you make it again."
-Franklin P. Jones


Actually there are three values that will determine how entities are handled by Epic.

I would double check the exact usage for reserved character usage. Both 8879 and the XML spec state that certain characters like the entity open (& and %) as well as the STAGO (<) will be entered as entities to avoid confusing the parser.

Lynn
---- "Paisley wrote:
> We had some issues with Epic 5.2 with entities being automatically
> converted. If I remember correctly the settings to look at are :
> charentdisplay (on)
> and
> entityinputconvert (off).
>
> Robert G. Paisley
> Northrop-Gruumman
> "Experience is that marvelous thing that enables you to recognize a
> mistake when you make it again."
> -Franklin P. Jones
>
>
>
Announcements