Re^2: Parsing dodgy XML

Likelihood of refusing bad XML tends towards zero as desperation to win new business tends towards infinity....

I will be giving them an XSD and a small script to test validation, but if they (and 'they' are a national newspaper) use the current XML, then getting them to change it may prove difficult.

Comment on Re^2: Parsing dodgy XML

Replies are listed 'Best First'.
Re^3: Parsing dodgy XML by merlyn (Sage) on Sep 20, 2006 at 15:42 UTC
If nobody tells them they are not generating XML, how will they know there's a problem? -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^4: Parsing dodgy XML by Anonymous Monk on Sep 20, 2006 at 19:46 UTC
They're the client; it's your job to make them happy. If they don't want to give you XML, they don't have to. If you want to get paid, you have to deal with what you're given, not what you wish you were given.	[reply]
Re^5: Parsing dodgy XML by bart (Canon) on Sep 21, 2006 at 06:26 UTC
Tell them you must charge more to correct their mistakes in what is not quite XML. Or, which might sound better to them (but means the same), you give a discount when their XML is XML. There's a reason why the standard of XML is as intolerant to dodgy pseudo-XML, as it is: to enforce it to people in cases like this. Use that power. Point to the standard.	[reply]
Re^5: Parsing dodgy XML by codeacrobat (Chaplain) on Sep 20, 2006 at 21:19 UTC
You can do so once, twice, maybe more. When things go bad it is always good to have stated "there is a risk". It is the clients job to decide to take the risk or not to take it. Clients don't know what they want. If you want to deliver real good work, you tell them what they might want and then go to work.	[reply]