Hi,
I would like to support this request, but broaden it so that its
usefulness is bigger.
The functionality that I think would be much more useful is to have not
only the possibility to validate in memory a given DOM-tree (for which
there indeed exists a work-around -however, see below), but the
functionality that I'm really looking for is to ask a given DOM-node
which attributes/child elements are allowed (and how many) according to
the schema. This would allow you to interactively edit a DOM-tree,
with suggestions which edits are possible.
>From the outside this looks a related topic: if validation fails, I
would like to know what the correct options are that would lead to
validation.
But here I might be completely wrong. I would like to hear Boris'
opinion.
Anyway, an api that supports this type f functionalty would be
extremely useful.
Now on the in-memory validation: my experience is that this works ok
if the validation succeeds. However, if validation fails and you want
to print details of what and where the error occurs, I always get core
dumps. So instead I serialise a DOM-tree first to a temporary file on
disk, the do the validation with possible error reporting on this
temporary file.
I would love to see how it is supposed to be done. Earlier requests
along this line in this newsgroup have not lead to any answer, but the
problem remains..
Kind Regards,
Bertwim
Vladimir Loubenski wrote:
Hi Boris,
Michael described Xerces-J
functionality to validate a DOM in-memory that we need for.
Could you consider to implement
it in a near future?
Thank you,
Vladimir Loubenski
Senior Software Developer
RD, Genio
Open
Text
38 Leek Crescent,
Richmond
Hill L4B-4N8 ONT
Canada
Phone:
+1 905 762 6001 ext. 6985
Email:
vloubens@opentext.com
Web site:
http://www.opentext.com/
This
email is protected by domestic and international copyright laws and
treaties and is the property of Open Text Corporation, it may contain
confidential and/or trade secret information of the Open Text
Corporation and/or its subsidiaries (OTC), and may be subject to legal
privilege in favor of OTC. This email may only be lawfully received,
accessed, displayed on a computer screen, printed, copied, and/or used
by the specific addressee(s) named above ("Authorized Recipient") for
the purpose for which it was sent by OTC. All other rights and licenses
to this email are fully reserved to OTC. If you are not an Authorized
Recipient, you are required to immediately delete this email in its
entirety without printing, copying, using, and/or re-transmitting this
email, either in whole or in part. The transmission of this email by
OTC is not to be construed as a waiver by OTC and/or the individual
sending this email on behalf of OTC of any of their respective rights
or privileges at law or otherwise, howsoever arising.
From: Michael
Glavassevich [mailto:mrgla...@ca.ibm.com]
Sent: July 30, 2010 11:21 AM
To: c-dev@xerces.apache.org
Subject: Re: Validate the data contained in a DOM tree
Boris,
Xerces-J has had the ability to validate a DOM in-memory for
years. It behaves as if you serialized and then reparsed the document
with schema validation enabled except that it's much more efficient
(firing SAX like events to the schema validator from a walk of the DOM
tree). I think that's what Vladimiris asking for,
not fail-fast setters / continuous validation which seems to be the
topic in the post you referenced.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
Boris Kolpackov bo...@codesynthesis.com wrote on
07/30/2010 11:07:24 AM:
Hi Vladimir,
Vladimir Loubenski vloub...@opentext.com writes:
My understanding that single way to validate data (Validation
against
XML schema) in a DOM tree is to create the DOM document,
write it back
as XML and re-parse it with validation turned on. Are there
plans to
support validation direct from the DOM tree?
No, there are no plans to support this at the moment. It is also
questionable how useful this feature will be since it is not clear
what one can do when a validation error has been detected. There
are some errors that will be hard/impossible to fix
programmatically
(say, pattern validation error). For a more detailed discussion of
this topic, see the following post:
