This is starting to sound like a toolkit bug. And as such probably on the wrong list.
But obviously you have a lot of people's active attention !
If you could post a code snippet may answer a thousand questions.
The one I have is
"Does the toolkit generate the bad XML or does the custom code?"
If the toolkit/framework is generating the XML and it passes through unescaped invalid XML markup then the toolkit has a bug and should be reported *to the toolkit developers*.
If custom code is generating bad XML then it needs to be fixed by the custom code developers.
In neither case is the "XML Spec" at fault here.
Any more than passing an extra "," to CSV or a UTF8 sequence to a Ascii parser or any of a thousand million zillion examples I could come up with offhand of invalid data to languages/parsers/tools which expect valid data.
It's pretty clear in XML specs what's valid and what is not. GIGO and all that ...
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
From: Stephen D Green [mailto:stephengreenubl@g...]
Sent: Sunday, July 17, 2011 6:12 PM
To: Andrew Welch
Cc: David Carlisle; xml-dev@l...
Subject: Re: Error and Fatal Error
I'll try and have a look at the code again tomorrow at work.
As far as I remember we do not have access to the strings.
These are *very* commonly used Ajax controls and they
probably bind to a dataset from http://ASP.NET 'markup'. Not
everything in controls like this is available to the developer.
If the controls do bind to a dataset (XML a la .NET) then
the data is possibly pre-packaged as XML even if it has '&'
in the element content. Besides, this is a framework we are
talking about so I do not have much say in what other
developers working now and in the future on the apps do.
One tends to stick with the framework (go with the flow) and
understand that others will try and do the same.
On 17 July 2011 22:26, David Carlisle <davidc@n...> wrote:
On 17/07/2011 22:13, Stephen D Green wrote:
I don't buy that. And not so easy to replace '<' with
'<' in just the element content and not the tags.
----
I thought you indicated that you were taking strings from user supplied form data and adding it to xml, in which case you need to escape the xml syntax characters before you add it to the xml so there is no element content and no tags to worry about. You don't want to add it then try to parse to find element content afterwards as if adding the content has made the xml non well formed you've already lost.
David
On 17 July 2011 22:26, Andrew Welch <andrew.j.welch@g...> wrote:
On 17 July 2011 22:13, Stephen D Green <stephengreenubl@g...> wrote:
> I don't buy that. And not so easy to replace '<' with
> '<' in just the element content and not the tags.
It really is straightforward... if you are adding to an in memory tree
just add the text as-is, if you are adding to serialised xml then just
put text through a serialiser first (by wrapping it in a root node,
serialising it, then substringing it out).
If that's not what you mean then can you do an example of the problem?
If the user is writing markup then it's back to helping them get it
right first time by parsing in the background and highlighting errors.
--
Andrew Welch
http://andrewjwelch.com
Cart
