RE: Authoring versus Interchange

Yes, or that those of us who are both here and there try to think about the
elements we come up with here when we try to develop the editing specs
further. Some of the work of the editing taskforce has already been about
trying to make editable html be closer to the semantic version used for
interchange.

For example, the list of "legal caret positions" was started because it was
impossible in most browsers to put the caret between certain types of
non-editable content (such as citations or inline formulas) unless one
added things such as text nodes containing zero-width spaces [1].

The editing tf should continue trying to work on these things, but text
editors currently do so many extra things with the DOM - such as manual
linebreaking by putting the contents of each line into it's own element -
that it will probably be a good while before the two can be the exact same.

[1] https://w3c.github.io/editing/contentEditable.html#terminology

Johannes,



Are you recommending working with http://www.w3.org/wiki/Editing_Taskforce?



Tzviya



*Tzviya Siegman*

Digital Book Standards & Capabilities Lead

Wiley

201-748-6884

tsiegman@wiley.com



*From:* Johannes Wilm [mailto:johanneswilm@vivliostyle.com]
*Sent:* Tuesday, December 01, 2015 9:02 AM
*To:* Robin Berjon
*Cc:* Florian Rivoal; public-scholarlyhtml@w3.org
*Subject:* Re: Authoring versus Interchange



Hey,

as someone who has worked on one of the academic authoring tools out there
for a while (Fidus Writer), for a long time I had a hard time understanding
what the difference between interchange and editing format is.



I don't think there needs to be such a clear distinction. The list I sent
over first of "requirements" to such files we have heard repetitively by
different users and potential users is for both. It just states the things
people often need to be able to store -- and therefore previous to that
author -- in such a file.



Now in reality, there is a difference: browser based editors seldom just
have the raw elements with nothing extra in the DOM. But that is generally
not because the editors want to have a distinction between exchange and
edit format, but because there are so many weird bugs and issues with
browser based editors that one needs to add these extra elements so that
the editing experience is more or less acceptable. For example, one often
needs to add extra <span>-elements just so that one can place an element a
specific place or so that the caret moves in a desired way. When saving the
file for interchange, one deletes that span again. Another case we found
with Fidus Writer was that we needed to support sibling text nodes for
collaboration -- and that's not really possible when just using plain HTML
to represent the DOM structure.



In conclusion: yes, let's focus on the interchange here. If we are
successful, and also the editing taskforce is able to work out the issues
there are with editing in browsers, hopefully the two types of formats
don't need to be so different in the future.







On Tue, Dec 1, 2015 at 6:20 AM, Robin Berjon <robin@berjon.com> wrote:

On 01/12/2015 00:13 , Florian Rivoal wrote:
> I agree, but would like to make one of your semi-implicit points
> fully explicit.
>
> While we should prioritize for interchange over manual authoring when
> there is a conflict, this should not mean that we should attach no
> importance to manual authoring. It is important, and we should make
> sure it is as nice as possible. Being secondary to interchange does
> not make it a non goal.
>
> I would not like to end up in a situation where we have a format that
> works great for interchange but cannot practically be edited by
> hand.
>
> This is not just about catering to people who like vim or emacs best
> as an authoring environment, but also about making sure the format
> remains inspectable, hackable and debuggable without (heavy) tools.
> Having humans form part of the ecosystem the format lives in is much
> healthier.

Absolutely, and thanks a lot for making that extra clear. If we wanted
something solely ideal for interchange, we'd use JSON ;)

Of the many equivalent ways of achieving high quality interchange, we
should always opt for the more authorable. We should have default values
and all the nice things that make this a language that wasn't designed
using XML Schema.


--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•