Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?

[Tupshin Harper]

Tom Lord wrote:

> Another issue here is that while OpenOffice promises to reasonably
> handle those files which conform to the various DTDs which it, itself,
> might have generated -- it does not promise to reasonably handle all
> files that conform to those DTDs.  Just as the DTDs are a subset of
> XML-in-general, the documents reasonably handled by OpenOffice is a
> subset (not a priori an improper or proper subset) of those XML docs
> that pass the DTDs.
>  
If so, then this is an OO bug which should be fixed. If DTDs are 
insufficient to represent all restrictions of the file format, then XSDs 
should be used. I very much doubt that XSDs at least have insufficient 
precision to constrain an XML file such that, if valid, it would be 
handleable by OO.

> I understand that that is a subtle point and that we most likely have
> a language barrier between us -- but do you see what I am saying?
>
>
>    > Example: [...]
>    > 
>    > If the DTD would indicate the colorlist could either be empty or contain 
>    > one 'color-item' child, patch should complain about a merge conflict and 
>    > ask the user to resolve.
>
> You're just restating the problem, not solving it.  How is the user to
> resolve this conflict, especially in the specific case of OpenOffice
> documents?  By editting the raw XML?  By editting the source documents
> in anticipation of how they will be handled by the diff/patch
> algorithms?
>  
OO should handle this by having an xdiff equivalent representation of 
the *rendered* document segment such that the user could select which 
one they want. Possibly have an option to view the underlying XML, but 
have the default be that the user gets to see two document segments side 
by side.

>    > Summary:
>
>    > Any good XML patch should take the DTD into account when
>    > merging. If it does not, you will be required to do more manual
>    > merging effort than needed.
>
> Again, you're just restating, not solving the problem.
>
> The DTD doesn't contain enough information for the patch tool to
> generate output which includes conflict markers.
>  
Agreed that handling conflict resolution outside of OO is not very 
viable. Any "end-user" focused conflict resolution needs to be done in 
the context of a gui that can display OO documents as documents and not 
raw xml.

> Therefore, the patch tool must sometimes say "I can't produce any
> useful output whatsoever" from the perspective of the tools who's DTDs
> we are trying to generate.   What the hell is supposed to happen then?
>
> -t
>  
Abort unless it can launch a conflict resolution tool or unless the 
patch tool is explicitly told to proceed even if it has to do so by 
creating an invalid xml file (equivalent to <<< style conflicts in 
regular source files).

Just thinking aloud on this last bit, but it seems reasonable. ;-)

-Tupshin