W3C home > Mailing lists > Public > public-xml-er@w3.org > February 2012

Re: Charter

From: George Cristian Bina <george@oxygenxml.com>
Date: Thu, 16 Feb 2012 07:10:18 +0200
Message-ID: <4F3C8FBA.8050103@oxygenxml.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: Shane McCarron <shane@aptest.com>, public-xml-er@w3.org
Hi all,

At XML Prague the point I tried to make was:

It would have been great is HTML would have been unified with XML in 
HTML 5, that is the XHTML 5 would have been the HTML 5 specification and 
a separate document would have described how a browser can recover if 
there are well-formed errors in the document.

As an XML editor developers we had this problem early on because when 
people edit the XML source the document is most of the time not 
well-formed. When we wanted to add a document outliner, which is a tree 
view showing the structure of the document then we had to solve this 
problem of being able to create a tree from whatever text we have in the 
editor, if that was well-formed XML then the tree needed to have the 
same structure as the corresponding DOM.

In this context we were not interested to get any errors or to 
distinguish between a wellformed document and a non wellformed one. In 
our case the error checking is orthogonal to the creation of the 
Outliner and even if the outliner will show a tree for a not well-formed 
document the validation part will show a fatal error.

There was another requirement, however. We needed to be able to react to 
incremental changes, to easily be able to obtain from the current text + 
current tree + a change on the text ---> the next tree. That is because 
we compute this in realtime (not on a separate thread) and we wanted to 
be able to react as the user changes the document without parsing 
everything from the start.
This goal influenced some of our decisions, for example if we have

<parent>
    <x>
      <y>
    ...
</parent>
...

we automatically close the parent element and all the other descendants 
that were not closed, like x and y in the above example, when we see the 
</parent> closing tag.
Thus, basically any changes inside the parent element will stay there 
and the tree will not change its structure dramatically when the user 
inserts a child element inside a parent, as in this process we pass 
exactly through such a case, when user inserted the start tag and he is 
about to enter the end tag.

I hope this helps!

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 2/16/12 2:32 AM, Noah Mendelsohn wrote:
>
>
> On 2/15/2012 3:04 PM, Shane McCarron wrote:
>> I concur.
>>
>> On 2/15/2012 2:01 PM, Robin Berjon wrote:
>>> On Feb 15, 2012, at 20:57 , Norman Walsh wrote:
>>>> How about if we soften it a bit:
>>>>
>>>> Applications that perform error recovery should provide a mechanism
>>>> for identifying when recovery was performed on a document.
>>> Ah yes that works for me; I think that error reporting (to
>>> developers) is
>>> very important when recovery happens.
>>>
>
> I'm a little nervous about mixing a specification for a tree mapping
> with a specification for a processor with a specification for an API. I
> would be happy if this group:
>
> * Produced specification for a mapping from (potentially poorly
> formed/erroneous) XML to a tree. Presumably, in the case where the XML
> is well formed, the tree should match or at least be close in spirit to
> the infoset (or XPath data model or DOM or whatever we think is the
> right point of reference.)
>
> * Demonstratated that implementations of the mapping are practical, and
> that it's possible to do streaming implementations.
>
> I suspect it's trivially true of most any mapping we would promote, but
> we should also show that it's >possible< for those who wish to to build
> APIs and/or applications that distinguish cases in which the input was
> well formed from cases where it wasn't.
>
> I don't think we should say anything about what a processor is, what a
> conforming processor is, or what APIs are preferred. People should
> design the APIs they need, with as much or as little error reporting as
> appropriate to the situation. Some APIs may wish to report not only that
> there were errors, but also to identify the parts of the tree in which
> they occurred. Others may wish to report a single (error/no-error) bit,
> or there may be situations in which no such reporting is needed.
>
> Noah
>
>
Received on Thursday, 16 February 2012 05:10:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 February 2012 05:10:46 GMT