Subject: [TOOLS-DEVELOPMENT] xmldiff-01

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Jul 2014 13:45:49 -0500

This reflects being able to run the application on a personal computer 
as well as having it run as part of a web service.

I _think_ that's all that we concluded on last weeks call. Please let me 
know if I forgot something that we settled.

RjS

---

From: Tony Hansen <[email-masked]>
Date: Thu, 17 Jul 2014 15:41:08 -0400

On 7/14/14, 2:45 PM, Robert Sparks wrote:
> I _think_ that's all that we concluded on last weeks call. Please let 
> me know if I forgot something that we settled.

Re "Changes in whitespace that are ...."

CDATA blocks do not affect whether whitespace is or is not significant. 
You can use a CDATA block anywhere you can use any other type of text, 
including normal text paragraphs. The interpretation of whitespace is 
orthogonal to how text is entered.

Instead, you might consider referencing <artwork> and <code> text blocks.

nit: "will be run a web" => "will be able to be run as a web"

The following needs to be discussed with the rfc-interest list and the 
rfc format design team:

One consideration we discussed last week for xmldiff was whether it 
should be possible to generate an xml2rfc xml output with differences 
designated.

One suggestion is that the xml2rfc grammar should support diff=deleted 
and diff=added attributes on various elements. This way, a paragraph 
that has been deleted could be rendered as something like this:
     <t diff='deleted'>This is the old text</t>
     <t diff='added'>This is the new text</t>
or
     <t>This is the <spanx diff='deleted'>old</spanx><spanx 
diff='added'>new</spanx> text</t>

This would then be rendered appropriately in the given output formats.

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 21:56:14 +0200

> This would then be rendered appropriately in the given output formats.

How do you handle added/removed section, title changes, etc?

Note that rfc2629.xslt has support for this via the undocumented ed: 
namespace, you can see it at work over here: 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-12.html>

(and no, the diffs were not autogenerated)

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Fri, 18 Jul 2014 11:35:26 -0400

> (and no, the diffs were not autogenerated)

Cool, running code.

Ok, sections should have diff= as well. And titles work just fine within 
the <titleelement> tag.

Since you've put some previous thought into this, how would YOU suggest 
handling added/removed sections, title changes, etc?

Can you describe more about the ed: namespace, since it's (as you say) 
undocumented?

To you, does it seem worth adding support for this to the v3 processor? 
Particularly given the desire we have for xmldiff. I could see it being 
done either as a direct set of elements/attributes, OR as a reference to 
a >>documented<< ed namespace (like we make reference to the xi:include 
facility).

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jul 2014 19:40:22 +0200

> Can you describe more about the ed: namespace, since it's (as you say)

Oh, it's mainly a copy of HTML's <ins> and <del>, with some additions:

- a <replace> container that can group an <ins> and a <del>

- some hacks to deal with changes in attributes

- some support to link edits to in-document issues (that's probably 
something we don't want to do)

> a >>documented<< ed namespace (like we make reference to the xi:include

I think I'd see it as something that can be done on top of the v3 
vocabulary. So define it as an extension vocabulary that imports the v3 
vocab and modifies it.

Yes, support in a v3 processor would be cool, but I'm a bit concerned 
about the scope...

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jul 2014 12:44:38 -0500

On 7/18/14, 12:40 PM, Julian Reschke wrote:
> vocabulary. So define it as an extension vocabulary that imports the 
> v3 vocab and modifies it.
>
Agreed - I don't see this diff being something that needs to be valid 
given the v3 grammar.
I'm not even sure it should be an extension of the v3 grammar, though it 
would clearly reuse chunks of that language.
I could see container elements, for instance, holding both an old and 
new chunk, or something similar.

>
> Best regards, Julian
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development