Some consideration about the xerces DOM implementation 2007-04-19 - By Michael Glavassevich
Hi Dick,
There is a DOM Level 3 Validation module [1] which provides an API for
guided editing of XML documents. Among other things, it has a
validateDocument() [2] method which explicitly prohibits mutation of the
DOM during validation. If there's ever an effort to make Xerces' DOM
implementation more friendly to schema guided editing, I'd rather see it
through an implementation of this API.
Thanks.
[1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/
[2]
http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/validation.html#VAL
-Interfaces-DocumentEditVAL-validateDocument
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@(protected)
E-mail: mrglavas@(protected)
Dick Deneer <d.deneer@(protected)> wrote on 04/18/2007 12:20:12 PM:
> I am using the xerces parser and Dom implementation as the base of a
> simple XML editor.
> The editor has a source and a tree (DOM) view.
>
> Using the DOM in an editor requires other functionalitiy then just
> using a DOM for showing or validating purposes.
> In fact there are two issues with the current
> implementation, making it very hard to use xerces for this purpose.
> 1. It may be clear that it is important that the user gets the same
> (or nearly the same) xml after switching from source to DOM and back.
> 2. The user don't want unexpected additions or mutations in the DOM
> while editing or validating.
>
> I will give some examples:
> � It is not possible store entity references in attribute
> values when building a DOM, making is impossible to get the original
> XML back after serializing. There is a jira issue for this problem, see
> https://issues.apache.org/jira/browse/XERCESJ-1225
> � The DOMNormalizer adds default required attributes to the DOM
> tree. Altough perfectly right according to the official
> specifications, this is not desired for the use in an editor.
> � First it will produce a error message "cvc-complex-type.4:
> Attribute 'xxxxx' must appear on element 'yyyyyy', which is in fact
> not valid anymore, because the problem is already solved by the
> DOMNormalizer, and secondly the XML is not the same anymore. These
> two things are confusing for the user. At this moment it is not
> happening for elements , but It looks like the same behavior is
> going to be implemented.
> � Adding a textNode which is adjacent to another, will
> immediately be delete by the DOMNormalizer. Again, this may be
> perfectly right, but confusing for a user when editing in a DOM.
> And it is not possible to validate the DOM without this "side-effect".
>
> Feedback of what happend is given by all kind of document events,
> which is great to still give some explanation to the user and keep
> trees in sync. But I would prefer to let some things not happen
> and be in control in the front.
> I really hope that in the future xerces will bring more "features or
> properties" to control the behavior of the DOMParser and DOMNormalizer.
>
> D. Deneer
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@(protected)
For additional commands, e-mail: j-dev-help@(protected)
|
|
