Some consideration about the xerces DOM implementation 2007-04-23 - By Dick Deneer
Michael,
Implementation of the validation api would be great. In fact it was one of
my first questions when I joined this forum. See
http://www.archivum.info/j-users@(protected)/2005-10/msg00010.html
The methods to know, if or what nodes can be inserted are of great value. I
tried to implement it myself but I gave up, because of the great complexity.
I understand that implementing this part of the API is not top priority
within the developer's team because it can be considered as extra or
nice-to-have, but I still hope that it will be implemented in the future.
On the other hand you can say that this is still a chance where one tool can
excel in comparison to others.
But I think that validating the dom without modifiying is much more basic
functionality. And all functionality (in fact too much :)) is already there
in the document.normalizeDocument() method. Maybe a reason too have this
available more soon.
Dick Deneer
Michael Glavassevich wrote:
>
> 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)
>
>
>
--
View this message in context: http://www.nabble.com/Some-consideration-about
-the-xerces-DOM-implementation-tf3602407.html#a10147485
Sent from the Xerces - J - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@(protected)
For additional commands, e-mail: j-dev-help@(protected)
|
|
