[XML-DEV Mailing List Archive Home]
[Reply To This Message]
Re: Error and Fatal Error
- From: Stephen D Green <email@example.com>
- To: David Lee <firstname.lastname@example.org>
- Date: Mon, 18 Jul 2011 10:07:22 +0100
There are always bugs. I don't see that as the issue; rather that we always have to
write even simple apps such that the bugs do not cause problems for the enduser.
In this case it means we have to anticipate errors and handle them gracefully. That
seems to be, as would be expected, only properly, emphasised in the XML spec
for behaviour of the conforming XML parser. At least that would be the intention of
the spec. The actual outcome in conforming software would depend on how good
the spec does its job (and how well the architects of XML and the XML spec
design understand the effect of the spec on implementers, which isn't easy to do
and requires feedback at all stages and possibly redesign as part of the spec's
maintenance). So here the spec wants the parser to be useful for what some are
calling preparsing - a step where errors are found and the application using the
parser gets an opportunity to correct them. This aspect of the parser/spec is what
I want to bring to peoples' attention so the spec can be improved rather than try
to work out why errors happen in the first place. If the spec attempts to allow for the
correction of errors it is doing better than just saying 'errors should never happen'.
Stephen D Green
On 18 July 2011 01:34, David Lee <email@example.com>
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
From: Stephen D Green [mailto:firstname.lastname@example.org]
Sent: Sunday, July 17, 2011 6:12 PM
To: Andrew Welch
Cc: David Carlisle; email@example.com
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 <firstname.lastname@example.org> 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.
On 17 July 2011 22:26, Andrew Welch <email@example.com> wrote:
On 17 July 2011 22:13, Stephen D Green <firstname.lastname@example.org> 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.
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please