XML in the attribute of other XML

Question

Today, another developer was talking to me about how he addressed an issue he was working on. The solution he found was to stick a string of escaped XML into the attribute of another XML element. In my head I was screaming "Is that even safe and wise to do???". According to him, that has been done on tons of other projects within the company that transmit XML back and forth.

My question is this -

1. Is that a safe/smart thing to do (xml in an xml attribute)?
2. If not, should I bring that up? I have only been with the company for 2 years and have noticed many things that are just asking for a major catastrophe to happen someday (both in and not in projects I work on). I don't want to be the one that always says that they are doing things wrong...

Any thoughts would be greatly appreciated!

FYI - UPDATED INFO RE: APPLICATION - Flash is calling this API and parsing the XML it gets in the response. I do not think the Flash is using XPath or anything, just string parsing (but I could be wrong). I do not work on the Flash aspect, so I do not know where to look (nor would I understand it).

Answer 1

If you properly escape the inner XML, then this CAN work. I'm not going to take bets on how long before you find oddball issues with the escaping, however.

I personally think it's a VERY strange thing to do, and I think it's going to cause lots of head scratching further down the line. More importantly (perhaps), it means that you can't use standard stuff to mess with the 'inner' XML directly - you'll always have to pull it out, de-escape it, and then you you can fool with it. Heck, you can't even apply XPATHs that will work with the inner XML, let alone something like XSLT.

I wouldn't do it, but then I don't know the problem at hand, so I can't be sure it isn't the best solution available out of a field of really horrible solutions.

Answer 2

Wow, this is totally wrong way to do things... Sure it can work, but why?

You've just added a whole new level of escaping and parsing that no other tool in the world can handle. What if you need to use an XSLT transform on it? How do you use XPATH on it? It's just extra work to get that data back out without any real benefit.

The proper way to do this, is put it as a sub-element of the element, which lets you put... surprisingly... more XML. Now it's only parsed once, you don't worry about escaping and double-parsing, and any XML tool will be able to read the structure.

The only complaint I can see about doing this is if the XML element content has a plain text-node content. In this case, simply move the text to another sub-element. It should be pretty simple to update any XPATH references to it.

Answer 3

If the escaped XML follows a specific format Use a Schema to define that format and put it where it belongs as another element. From the sounds of things, the app isn't using a schema and the parsing is done by hand...there are a lot of formats better suited for transmitting data than XML so I guess my question is why is the program using XML in the first place.

Seems like there's a lot wrong but without first hand knowledge I couldn't begin to suggest how to fix it.

Answer 4

1. It will break the data format unless unless you HTML encode the inner XML then it should do the trick.

2. It is probably safe but... weird. There is always a better way.

---

The only valid reason I can think of is attempting to pass extra or new information over an interface which cannot be changed/extended for some reason. Then you have to find a way to "squeeze" new data into an old format. Maybe it's an old and established interface which has been thoroughly tested, approved and certified. The the cost of changing it would be immense.

Other than that... well... weird as I said...

Answer 5

This is a clear indicator, that the outer markup is flawed and should therefore be fixed.
XML attributes are meant for flat values.

Of course you can do it. SVG shows, you can even make a standard of it, although there are clear benefits in that case.

In your case however, the data in question must be a child instead of an attribute. Full stop.

Answer 6

I did exactly this and I want to explain in what sense it was correct.

I was using a framework that duplicates data across a network. A server maintains the data. Clients can subscribe to a view on the data. They receive the current state and are later notified of any changes. Changes would be adding or removing a data entity, setting an entity field value, or setting a relation between entities.

The current state and data was encoded in XML. For instance, if a product is reserved and availability changes, the client could receive an update like:

<upd type="product" id="678" available="19" reserved="1" />

All primitive fields values are given as attributes.

What happened then is that one field coming from the DB contained XML. It was stored as an XML string because only the client needed to interpret it. So, the XML, as any string, was properly escaped and passed as an attribute.

Morality

There is nothing wrong, it is just isolation between two layers.

The lower layer transports strings, among other things, and happens to represent strings as XML attributes. The upper layer needed to transport XML and naturally used the string representation of XML. The combined effect is that you get XML encoded in an attribute.

Detecting that situation and moving that XML to a nested element (as my boss wanted me to do) would break the independence of the layers. The upper layer would have to tag the field as "this is properly formed XML", and the lower layer would then say "nice, I will pass it as a nested element".

To show that it is wrong, imagine the lower layer is one day replaced to use JSON. Now it needs to be notified of data that is properly formatted JSON. But the upper layer shouldn't be affected by changes in the implementation of the lower layer.

Answer 7

Converting XML to escaped text is effectively destroying this markup -- flattening it into one dimension only.

This is for the tag "worst practices" -- not "best-practices.