Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   XML (http://www.velocityreviews.com/forums/f32-xml.html)
-   -   Design & Implementation for validating XML documents (http://www.velocityreviews.com/forums/t622729-design-and-implementation-for-validating-xml-documents.html)

mathieu 06-28-2008 12:12 PM

Design & Implementation for validating XML documents
 
Hi there,

Could someone please suggest an open source implementation of a
validating XML parser ? I am interested in how this thing can
(should?) be designed. In particular how the errors should be handle:
1. If one at a time, it make is difficult to handle from a GUI, since
only one error can be corrected at a time
2. All errors are reported, which means that false positive may be
reported
Also how does the implementation report which elements contains
errors (using name, file position...).

Thanks
-Mathieu

Martin Honnen 06-28-2008 12:22 PM

Re: Design & Implementation for validating XML documents
 
mathieu wrote:

> Could someone please suggest an open source implementation of a
> validating XML parser ?


Apache Xerces has a Java and a C++ version: http://xerces.apache.org/

--

Martin Honnen
http://JavaScript.FAQTs.com/

Peter Flynn 06-28-2008 11:13 PM

Re: Design & Implementation for validating XML documents
 
mathieu wrote:
> Hi there,
>
> Could someone please suggest an open source implementation of a
> validating XML parser ?


SP is at ftp://ftp.jclark.com/pub/sp/sp-1.3.4.tar.gz
rxp is at http://www.inf.ed.ac.uk/research/isd...e?view=1&id=80

> I am interested in how this thing can
> (should?) be designed. In particular how the errors should be handle:


This is always a problem, since the author cannot know what the user
wants to do on a given occasion: stop or continue.

> 1. If one at a time, it make is difficult to handle from a GUI, since
> only one error can be corrected at a time


And when the first error is corrected, the validation must start again
from the beginning.

> 2. All errors are reported, which means that false positive may be
> reported


This is very common because an error may not be recognisable as such
until some later condition makes it impossible to continue.

> Also how does the implementation report which elements contains
> errors (using name, file position...).


onsgmls reports line number and character position, and optionally the
names of open entities. In a synchronous typographical interface, an
error can be indicated by many means (highlighting, change of focus,
error log, ...)

///Peter
--
XML FAQ: http://xml.silmaril.ie/

Joseph J. Kesselman 06-30-2008 02:05 PM

Re: Design & Implementation for validating XML documents
 
mathieu wrote:
> 1. If one at a time, it make is difficult to handle from a GUI, since
> only one error can be corrected at a time
> 2. All errors are reported, which means that false positive may be
> reported


> Also how does the implementation report which elements contains
> errors (using name, file position...).


I honestly believe XPath to the offending point is a more meaningful way
to report this, but whether it's more useful depends in part on the
quality of the tooling available to the user (and/or the user's skill
level).


All times are GMT. The time now is 04:49 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.