Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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).

share|improve this question
4  
I think I saw something like this recently on the DailyWTF. It was HTML encoded XML as the body of an XML message, or something like that. –  FrustratedWithFormsDesigner Jan 20 '11 at 22:30
1  
Isn't there a CDATA attribute that can do things like that more easily? –  Michael K Jan 20 '11 at 22:35
    
Safe? Sort of, if everyone escapes things properly. Smart? Hell, no. –  biziclop Jan 21 '11 at 0:29
2  
This makes me want to cry. –  sevenseacat Jan 21 '11 at 8:24
    
I've run across this approach in the wild, and it sickened me. There may be a time and place for it, but agreed with Mike Brown - that's what a nested element is for. –  Michael Urman Jan 21 '11 at 14:28
add comment

6 Answers

up vote 6 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Oh I am not looking for a better way - I know the better way. I am just not sure if I should raise my concerns. They have done it this way for years - who am I to tell them to change? –  Dan Appleyard Jan 21 '11 at 0:13
add comment
  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...

share|improve this answer
    
The attribute in question is completely new and it is part of a API that was built in house. Code would have to be written to even do anything with this new data. –  Dan Appleyard Jan 20 '11 at 22:44
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.