29 November 2004

Validation error: How do I fix a validation error?

Summary

Validation. Is it something the user needs to worry about? Sure, if there's a flaw in the user-controlled entries.

Validation is also something that can be stifling, even for developers. This blog entry outlines a case study in reading validation reports and shares an anecdote for validation developers. Ref

Information

One important thing is to make sure you're validating an XML-feed, not the URL of site.

Let's take a look at a sample problem.

This blog entry outlines a problem with a validator and the commentary below identifies the solution.

New users, not knowing the nature of the error or the nuances of XML vs HMTL; or RSS vs XML, may have quite a different view, albeit flawed, when provided the following information in the feed-validation error-report:

1. Feeds must not contain SYSTEM entities 1 108
2. Undefined root element: xhtml:html 3 0
3. XML Parsing error: :359:100: not well-formed (invalid token) 359 100
The challenge for developers and users is to "translate the error-code report" into meaningful information--something that is actionable.Ref

In the ideal world "it would be good" if all the auto-mated validators said, "This is not a XML feed, but a URL." Ref

The following is less desirable:

Note: If you get error message like this, you may not be using a feed.

The next issue is then to suggest to the user-tester, "Do X, Y, Z" to find a valid XML-feed. Again, some users need to be walked through the steps. Others, more advanced, will roll their eyes thinking, "Uh...I goofed" and laugh it off.

The current validators do not always, but sometimes, provide suggestions on the nature of the problem; what the potential solution is.

In this case, the "mid-term solution" is to change the entry into the RSS-validator.

Yes, a simple error. But imagine the users' turmoil when they are correctly told, "You do not have a valid feed" but it is for the "wrong" reason: In reality, nothing to do with the feed [a separate issue], but because of "operator error".

Users make errors. Validators, the good ones, should guide the new user to provide the correct information to make sure the human-errors are overcome and solved.

The next challenge is to figure out what the actual XML-related errors are in the various feed. Ref

Summary

This note outlines the importance to the XML community of keeping the user in mind. When the user thinks, "Pipeline," they are not thinking of software development, but the pipe of information from their blog to the reader's eyes.

Users make blunders an expert code writer would never dream making. Users also get lost in even the best designed XML-feeds.

Validation is an important step in ensuring the XML-related errors are cleaned up. The great developers create applications that overcome the inherent defects of the users [read "human error"], rather than compound them.

Momentarily put aside the elegant XML standards when you stress test your code and software solutions. Design for the user and their frailties.

Users may have computers, but they are not XML Wizards -- You are. Hence, we bow to thee.
Summary

Validation. Is it something the user needs to worry about? Sure, if there's a flaw in the user-controlled entries.

Validation is also something that can be stifling, even for developers. This blog entry outlines a case study in reading validation reports and shares an anecdote for validation developers. Ref

Information

One important thing is to make sure you're validating an XML-feed, not the URL of site.

Let's take a look at a sample problem.

This blog entry outlines a problem with a validator and the commentary below identifies the solution.

New users, not knowing the nature of the error or the nuances of XML vs HMTL; or RSS vs XML, may have quite a different view, albeit flawed, when provided the following information in the feed-validation error-report:

1. Feeds must not contain SYSTEM entities 1 108
2. Undefined root element: xhtml:html 3 0
3. XML Parsing error: :359:100: not well-formed (invalid token) 359 100
The challenge for developers and users is to "translate the error-code report" into meaningful information--something that is actionable.Ref

In the ideal world "it would be good" if all the auto-mated validators said, "This is not a XML feed, but a URL." Ref

The following is less desirable:

Note: If you get error message like this, you may not be using a feed.

The next issue is then to suggest to the user-tester, "Do X, Y, Z" to find a valid XML-feed. Again, some users need to be walked through the steps. Others, more advanced, will roll their eyes thinking, "Uh...I goofed" and laugh it off.

The current validators do not always, but sometimes, provide suggestions on the nature of the problem; what the potential solution is.

In this case, the "mid-term solution" is to change the entry into the RSS-validator.

Yes, a simple error. But imagine the users' turmoil when they are correctly told, "You do not have a valid feed" but it is for the "wrong" reason: In reality, nothing to do with the feed [a separate issue], but because of "operator error".

Users make errors. Validators, the good ones, should guide the new user to provide the correct information to make sure the human-errors are overcome and solved.

The next challenge is to figure out what the actual XML-related errors are in the various feed. Ref

Summary

This note outlines the importance to the XML community of keeping the user in mind. When the user thinks, "Pipeline," they are not thinking of software development, but the pipe of information from their blog to the reader's eyes.

Users make blunders an expert code writer would never dream making. Users also get lost in even the best designed XML-feeds.

Validation is an important step in ensuring the XML-related errors are cleaned up. The great developers create applications that overcome the inherent defects of the users [read "human error"], rather than compound them.

Momentarily put aside the elegant XML standards when you stress test your code and software solutions. Design for the user and their frailties.

Users may have computers, but they are not XML Wizards -- You are. Hence, we bow to thee.
" />