From nobody Mon Nov 10 11:35:37 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA81AC433 for ; Mon, 10 Nov 2014 11:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plv4mgocs6UH for ; Mon, 10 Nov 2014 11:35:32 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id C879E1AC434 for ; Mon, 10 Nov 2014 11:35:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 313D11E5A0A; Mon, 10 Nov 2014 11:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqvt3ExD32tY; Mon, 10 Nov 2014 11:35:01 -0800 (PST) Received: from dhcp-a784.meeting.ietf.org (dhcp-a784.meeting.ietf.org [31.133.167.132]) by c8a.amsl.com (Postfix) with ESMTPA id E0E9B1E5A05; Mon, 10 Nov 2014 11:35:00 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sandy Ginoza In-Reply-To: <53AC5FA6.5030003@nostrum.com> Date: Mon, 10 Nov 2014 09:35:31 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> References: <53AC5FA6.5030003@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/H0A_NdVpZsJ42ZF-WNFIVJM8KM4 Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:35:34 -0000 Hi Robert, At the last IETF, we talked about having a tool that would allow us to = run diffs across formats. This suggestion came up again at the IESG = breakfast when the members were discussing how the review documents = while reviewing Internet-Drafts.=20 This tool would be extremely helpful to the RPC (and others, it sounds = like) in ensuring that diffs appear only where we expect them (e.g., the = text file might have =93see Figure 1 in the PDF=94 and the PDF would = just have the image as expected). This would allow us to quickly see = that these discrepancies only appear where we expect them. =20 Can we add this as a feature to this writeup? Or is this meant to focus = on source file diffs only?=20 Thanks! Sandy On Jun 26, 2014, at 8:00 AM, Robert Sparks wrote: > Attached is another strawman to give us a place to start discussion = from. > IIRC xml differencing in the general case has some hard problems. > Is what this strawman starts to describe feasible? > Does anyone know of programs that do a lot of this already > (that would have a similar relation that wdiff has to rfcdiff)? >=20 > RjS >=20 > = _________________________________________= ______ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Nov 10 11:41:16 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56E1AC3CD for ; Mon, 10 Nov 2014 11:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69AfwwRI1urZ for ; Mon, 10 Nov 2014 11:41:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658C01A0161 for ; Mon, 10 Nov 2014 11:41:05 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAAJeew8034687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 13:40:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <546114B7.9080703@nostrum.com> Date: Mon, 10 Nov 2014 09:40:39 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sandy Ginoza References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> In-Reply-To: <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/AqeeK6olqdXgvtlJCkJFIqw3jY0 Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:41:11 -0000 The xmlDiff tool focuses on the source files. We already have a really good text diff tool, that I expect will work with no, or very little, adjustment. HTML and PDF diffing are different problems. We can look into what it would take to provide good differencing there, but that shouldn't be part of this xmldiff effort. RjS On 11/10/14 9:35 AM, Sandy Ginoza wrote: > Hi Robert, > > At the last IETF, we talked about having a tool that would allow us to run diffs across formats. This suggestion came up again at the IESG breakfast when the members were discussing how the review documents while reviewing Internet-Drafts. > > This tool would be extremely helpful to the RPC (and others, it sounds like) in ensuring that diffs appear only where we expect them (e.g., the text file might have “see Figure 1 in the PDF” and the PDF would just have the image as expected). This would allow us to quickly see that these discrepancies only appear where we expect them. > > Can we add this as a feature to this writeup? Or is this meant to focus on source file diffs only? > > Thanks! > Sandy > > > On Jun 26, 2014, at 8:00 AM, Robert Sparks wrote: > >> Attached is another strawman to give us a place to start discussion from. >> IIRC xml differencing in the general case has some hard problems. >> Is what this strawman starts to describe feasible? >> Does anyone know of programs that do a lot of this already >> (that would have a similar relation that wdiff has to rfcdiff)? >> >> RjS >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Nov 10 11:47:42 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6721ACC86 for ; Mon, 10 Nov 2014 11:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XioZDVUuVPt for ; Mon, 10 Nov 2014 11:47:39 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id BA11C1ACC84 for ; Mon, 10 Nov 2014 11:47:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 107A31E5A06; Mon, 10 Nov 2014 11:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h74W5u8jXYWD; Mon, 10 Nov 2014 11:47:07 -0800 (PST) Received: from dhcp-a784.meeting.ietf.org (dhcp-a784.meeting.ietf.org [31.133.167.132]) by c8a.amsl.com (Postfix) with ESMTPA id BB7421E5A04; Mon, 10 Nov 2014 11:47:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sandy Ginoza In-Reply-To: <546114B7.9080703@nostrum.com> Date: Mon, 10 Nov 2014 09:47:38 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> <546114B7.9080703@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/CXWGZcHt0asDsXlOUS7Yb13pMPQ Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:47:41 -0000 On Nov 10, 2014, at 9:40 AM, Robert Sparks wrote: > The xmlDiff tool focuses on the source files. Ok. > We already have a really good text diff tool, that I expect will work = with no, or very little, adjustment. > HTML and PDF diffing are different problems. We can look into what it = would take to provide good differencing there, but that shouldn't be = part of this xmldiff effort. I=92m not sure I=92m explaining myself. I=92m hoping for a tool that = will diff across formats; e.g., compares .txt with .html/.pdf output. = There should be no differences between .html/.pdf but there might be = differences between .html/.pdf. I=92m hoping for a tool that makes it = easy for us to identify the differences in output of the various = formats. Thanks, Sandy >=20 > RjS >=20 > On 11/10/14 9:35 AM, Sandy Ginoza wrote: >> Hi Robert, >>=20 >> At the last IETF, we talked about having a tool that would allow us = to run diffs across formats. This suggestion came up again at the IESG = breakfast when the members were discussing how the review documents = while reviewing Internet-Drafts. >>=20 >> This tool would be extremely helpful to the RPC (and others, it = sounds like) in ensuring that diffs appear only where we expect them = (e.g., the text file might have =93see Figure 1 in the PDF=94 and the = PDF would just have the image as expected). This would allow us to = quickly see that these discrepancies only appear where we expect them. >>=20 >> Can we add this as a feature to this writeup? Or is this meant to = focus on source file diffs only? >>=20 >> Thanks! >> Sandy >>=20 >>=20 >> On Jun 26, 2014, at 8:00 AM, Robert Sparks = wrote: >>=20 >>> Attached is another strawman to give us a place to start discussion = from. >>> IIRC xml differencing in the general case has some hard problems. >>> Is what this strawman starts to describe feasible? >>> Does anyone know of programs that do a lot of this already >>> (that would have a similar relation that wdiff has to rfcdiff)? >>>=20 >>> RjS >>>=20 >>> = _________________________________________= ______ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >=20 From nobody Mon Nov 10 11:56:03 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5A91ACD54 for ; Mon, 10 Nov 2014 11:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHe84Hq7wqtM for ; Mon, 10 Nov 2014 11:55:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF771ACD4A for ; Mon, 10 Nov 2014 11:55:41 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAAJtTAQ036432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 13:55:30 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <54611830.8090209@nostrum.com> Date: Mon, 10 Nov 2014 09:55:28 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sandy Ginoza References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> <546114B7.9080703@nostrum.com> <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> In-Reply-To: <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/pVPzGaWb-7iMpgAgoDMFq-qnE8w Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:55:52 -0000 On 11/10/14 9:47 AM, Sandy Ginoza wrote: > On Nov 10, 2014, at 9:40 AM, Robert Sparks wrote: > >> The xmlDiff tool focuses on the source files. > Ok. > >> We already have a really good text diff tool, that I expect will work with no, or very little, adjustment. >> HTML and PDF diffing are different problems. We can look into what it would take to provide good differencing there, but that shouldn't be part of this xmldiff effort. > I’m not sure I’m explaining myself. I’m hoping for a tool that will diff across formats; e.g., compares .txt with .html/.pdf output. There should be no differences between .html/.pdf but there might be differences between .html/.pdf. I’m hoping for a tool that makes it easy for us to identify the differences in output of the various formats. Ok. I hadn't gotten that yet. I'll think that through, but my initial reaction is that you're asking for something very hard (Artificial Intelligence level hard). Instead, perhaps we should be talking about adding requirements to the rendering tools that issue warnings when they know they're doing something that will result in what you would consider to be a difference between the rendered formats? > > Thanks, > Sandy > >> RjS >> >> On 11/10/14 9:35 AM, Sandy Ginoza wrote: >>> Hi Robert, >>> >>> At the last IETF, we talked about having a tool that would allow us to run diffs across formats. This suggestion came up again at the IESG breakfast when the members were discussing how the review documents while reviewing Internet-Drafts. >>> >>> This tool would be extremely helpful to the RPC (and others, it sounds like) in ensuring that diffs appear only where we expect them (e.g., the text file might have “see Figure 1 in the PDF” and the PDF would just have the image as expected). This would allow us to quickly see that these discrepancies only appear where we expect them. >>> >>> Can we add this as a feature to this writeup? Or is this meant to focus on source file diffs only? >>> >>> Thanks! >>> Sandy >>> >>> >>> On Jun 26, 2014, at 8:00 AM, Robert Sparks wrote: >>> >>>> Attached is another strawman to give us a place to start discussion from. >>>> IIRC xml differencing in the general case has some hard problems. >>>> Is what this strawman starts to describe feasible? >>>> Does anyone know of programs that do a lot of this already >>>> (that would have a similar relation that wdiff has to rfcdiff)? >>>> >>>> RjS >>>> >>>> _______________________________________________ >>>> TOOLS-DEVELOPMENT mailing list >>>> TOOLS-DEVELOPMENT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Nov 10 16:14:26 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417D71AD0BD for ; Mon, 10 Nov 2014 16:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idwD1s0PMhxh for ; Mon, 10 Nov 2014 16:14:24 -0800 (PST) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5587F1ACFFE for ; Mon, 10 Nov 2014 16:14:24 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id sAB0EM9t030571 for ; Mon, 10 Nov 2014 18:14:23 -0600 Received: from vpn-135-70-98-50.vpn.swst.att.com ([135.70.98.50]) by maillennium.att.com (mailgw1) with ESMTP id <20141111001422gw100r93foe>; Tue, 11 Nov 2014 00:14:22 +0000 X-Originating-IP: [135.70.98.50] Message-ID: <546154DD.5060802@att.com> Date: Mon, 10 Nov 2014 19:14:21 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: IETF Tools Development References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> <546114B7.9080703@nostrum.com> <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> <54611830.8090209@nostrum.com> In-Reply-To: <54611830.8090209@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/xR9P4EIQfjAPJth4ZyqsnqD110o Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:14:25 -0000 On 11/10/14, 2:55 PM, Robert Sparks wrote: > > On 11/10/14 9:47 AM, Sandy Ginoza wrote: >> On Nov 10, 2014, at 9:40 AM, Robert Sparks wrote: >> >>> The xmlDiff tool focuses on the source files. >> Ok. >> >>> We already have a really good text diff tool, that I expect will >>> work with no, or very little, adjustment. >>> HTML and PDF diffing are different problems. We can look into what >>> it would take to provide good differencing there, but that shouldn't >>> be part of this xmldiff effort. >> I’m not sure I’m explaining myself. I’m hoping for a tool that will >> diff across formats; e.g., compares .txt with .html/.pdf output. >> There should be no differences between .html/.pdf but there might be >> differences between .html/.pdf. I’m hoping for a tool that makes it >> easy for us to identify the differences in output of the various >> formats. > Ok. I hadn't gotten that yet. > > I'll think that through, but my initial reaction is that you're asking > for something very hard (Artificial Intelligence level hard). If we were to do a simple .txt vs .html comparison, there are certainly things that would keep showing up as false positives because of the inherent differences between the formats. For example, the .txt might format links in a way different from the .html; headers and footers are in the .txt and not in the .html; the order of data in the document header may be totally different; asides may wind up in different order within the documents; etc. With PDF, there is the addiitonal issue that blocks of words have coordinates associated with them, and those coordinates need to be ordered prior to looking at the underlying text. Working around those issues is where the difficulty could come in. > Instead, perhaps we should be talking about adding requirements to the > rendering tools that issue warnings when they know they're doing > something that will result in what you would consider to be a > difference between the rendered formats? I think this sentence is totally missing Sandy's point. It's not the KNOWN and EXPECTED differences that Sandy is worried about, but the UNKNOWN differences. Tony Hansen From nobody Mon Nov 10 16:33:05 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD10A1AD28D for ; Mon, 10 Nov 2014 16:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHV08jMjXdKo for ; Mon, 10 Nov 2014 16:33:03 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398901ACE98 for ; Mon, 10 Nov 2014 16:33:03 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAB0X2w5060932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Nov 2014 18:33:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <5461593D.7010707@nostrum.com> Date: Mon, 10 Nov 2014 14:33:01 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tools-development@ietf.org References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> <546114B7.9080703@nostrum.com> <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> <54611830.8090209@nostrum.com> <546154DD.5060802@att.com> In-Reply-To: <546154DD.5060802@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/0Gcwr8cbupASs9_iPTM8OQI2mUk Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:33:05 -0000 On 11/10/14 2:14 PM, Tony Hansen wrote: > On 11/10/14, 2:55 PM, Robert Sparks wrote: >> >> On 11/10/14 9:47 AM, Sandy Ginoza wrote: >>> On Nov 10, 2014, at 9:40 AM, Robert Sparks >>> wrote: >>> >>>> The xmlDiff tool focuses on the source files. >>> Ok. >>> >>>> We already have a really good text diff tool, that I expect will >>>> work with no, or very little, adjustment. >>>> HTML and PDF diffing are different problems. We can look into what >>>> it would take to provide good differencing there, but that >>>> shouldn't be part of this xmldiff effort. >>> I’m not sure I’m explaining myself. I’m hoping for a tool that will >>> diff across formats; e.g., compares .txt with .html/.pdf output. >>> There should be no differences between .html/.pdf but there might be >>> differences between .html/.pdf. I’m hoping for a tool that makes it >>> easy for us to identify the differences in output of the various >>> formats. >> Ok. I hadn't gotten that yet. >> >> I'll think that through, but my initial reaction is that you're >> asking for something very hard (Artificial Intelligence level hard). > > If we were to do a simple .txt vs .html comparison, there are > certainly things that would keep showing up as false positives because > of the inherent differences between the formats. For example, the .txt > might format links in a way different from the .html; headers and > footers are in the .txt and not in the .html; the order of data in the > document header may be totally different; asides may wind up in > different order within the documents; etc. > > With PDF, there is the addiitonal issue that blocks of words have > coordinates associated with them, and those coordinates need to be > ordered prior to looking at the underlying text. > > Working around those issues is where the difficulty could come in. > >> Instead, perhaps we should be talking about adding requirements to >> the rendering tools that issue warnings when they know they're doing >> something that will result in what you would consider to be a >> difference between the rendered formats? > > I think this sentence is totally missing Sandy's point. It's not the > KNOWN and EXPECTED differences that Sandy is worried about, but the > UNKNOWN differences. Something about unknowns unknowns? I don't think I've missed her point, actually. There is one activity where you look at places that are different in the renderings on purpose to make sure the differences are what we expect. I think it will be relatively easy to help see those efficiently by pointing to them as we render. I also think these are the kinds of places (like the difference between ascii vs svg art) that Sandy was originally intending to point to. There is another activity where you are looking to see if there is a bug in the rendering code that has produced an unexpected difference (some section's numbering is being rendered incorrectly, or a block of text was entirely missing). Finding those after the rendering is done will be hard, and I'm almost ready to argue that there's no way we can guarantee mechanical identification of them. Rather it's a job for a brain to look at these things. Now, maybe what we can provide is a good way to look at these side-by-side and help control keeping the two views in sync. But finding a way to perform a diff, and sensibly display that diff for the general case of changes in the presentation formats is not something I see happening. At best, I think it will devolve to what I think you're hinting at above - we postprocess each of the formats back into as much of a text representation as we can get out of them and running a diff on that. > > Tony Hansen > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Wed Nov 12 15:50:24 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC91A006E for ; Wed, 12 Nov 2014 15:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-i4UddWUF-u for ; Wed, 12 Nov 2014 15:50:16 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7761A0012 for ; Wed, 12 Nov 2014 15:50:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 64BC51E5A18; Wed, 12 Nov 2014 15:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao09AJtw10Jq; Wed, 12 Nov 2014 15:49:36 -0800 (PST) Received: from dhcp-a784.meeting.ietf.org (dhcp-a784.meeting.ietf.org [31.133.167.132]) by c8a.amsl.com (Postfix) with ESMTPA id 11BBB1E5A0F; Wed, 12 Nov 2014 15:49:36 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sandy Ginoza In-Reply-To: <5461593D.7010707@nostrum.com> Date: Wed, 12 Nov 2014 13:50:16 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <51F2083A-89D6-4DF2-BE3E-531021D698F0@amsl.com> References: <53AC5FA6.5030003@nostrum.com> <1E5237E5-AFBC-4680-AB44-549A444AB747@amsl.com> <546114B7.9080703@nostrum.com> <9B6E392E-D0A0-45BB-AD25-DF1A332890E6@amsl.com> <54611830.8090209@nostrum.com> <546154DD.5060802@att.com> <5461593D.7010707@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/eOgtwPE83j0eeYWBRLRSpyGPLY0 Cc: tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] xmlDIff-00 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:50:19 -0000 On Nov 10, 2014, at 2:33 PM, Robert Sparks wrote: >=20 > On 11/10/14 2:14 PM, Tony Hansen wrote: >> On 11/10/14, 2:55 PM, Robert Sparks wrote: >>>=20 >>> On 11/10/14 9:47 AM, Sandy Ginoza wrote: >>>> On Nov 10, 2014, at 9:40 AM, Robert Sparks = wrote: >>>>=20 >>>>> The xmlDiff tool focuses on the source files. >>>> Ok. >>>>=20 >>>>> We already have a really good text diff tool, that I expect will = work with no, or very little, adjustment. >>>>> HTML and PDF diffing are different problems. We can look into what = it would take to provide good differencing there, but that shouldn't be = part of this xmldiff effort. >>>> I=92m not sure I=92m explaining myself. I=92m hoping for a tool = that will diff across formats; e.g., compares .txt with .html/.pdf = output. There should be no differences between .html/.pdf but there = might be differences between .html/.pdf. I=92m hoping for a tool that = makes it easy for us to identify the differences in output of the = various formats. >>> Ok. I hadn't gotten that yet. >>>=20 >>> I'll think that through, but my initial reaction is that you're = asking for something very hard (Artificial Intelligence level hard). >>=20 >> If we were to do a simple .txt vs .html comparison, there are = certainly things that would keep showing up as false positives because = of the inherent differences between the formats. For example, the .txt = might format links in a way different from the .html; headers and = footers are in the .txt and not in the .html; the order of data in the = document header may be totally different; asides may wind up in = different order within the documents; etc. >>=20 >> With PDF, there is the addiitonal issue that blocks of words have = coordinates associated with them, and those coordinates need to be = ordered prior to looking at the underlying text. >>=20 >> Working around those issues is where the difficulty could come in. >>=20 >>> Instead, perhaps we should be talking about adding requirements to = the rendering tools that issue warnings when they know they're doing = something that will result in what you would consider to be a difference = between the rendered formats? >>=20 >> I think this sentence is totally missing Sandy's point. It's not the = KNOWN and EXPECTED differences that Sandy is worried about, but the = UNKNOWN differences. > Something about unknowns unknowns? >=20 > I don't think I've missed her point, actually. >=20 > There is one activity where you look at places that are different in = the renderings on purpose to make sure the differences are what we = expect. > I think it will be relatively easy to help see those efficiently by = pointing to them as we render. > I also think these are the kinds of places (like the difference = between ascii vs svg art) that Sandy was originally intending to point = to. >=20 > There is another activity where you are looking to see if there is a = bug in the rendering code that has produced an unexpected difference = (some section's numbering is being rendered incorrectly, or a block of = text was entirely missing). Finding those after the rendering is done = will be hard, and I'm almost ready to argue that there's no way we can = guarantee mechanical identification of them. Rather it's a job for a = brain to look at these things. Now, maybe what we can provide is a good = way to look at these side-by-side and help control keeping the two views = in sync. But finding a way to perform a diff, and sensibly display that = diff for the general case of changes in the presentation formats is not = something I see happening. At best, I think it will devolve to what I = think you're hinting at above - we postprocess each of the formats back = into as much of a text representation as we can get out of them and = running a diff on that. I am hoping for a tool that will identify differences, expected or = otherwise, across formats. Warnings would work, but they=92d be my = second choice. I=92m worried about places like when the text file will = point to a figure in the PDF/HTML (e.g., does the pointer that is in = place of an image that points to the PDF/HTML point appear as = expected?), and I=92m also worried about things like UTF-8-encoded chars = appearing differently in the text (not sure how big of a worry that is, = but it is something I think we could easily miss during a visual check). Thanks, Sandy >=20 >>=20 >> Tony Hansen >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 From nobody Mon Nov 24 08:28:57 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438541A6FFD for ; Mon, 24 Nov 2014 08:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbBU7r37F11c for ; Mon, 24 Nov 2014 08:28:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53AC1A6EEF for ; Mon, 24 Nov 2014 08:28:48 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAOGSl1u010044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Nov 2014 10:28:48 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <54735CBB.4000301@nostrum.com> Date: Mon, 24 Nov 2014 10:28:43 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: IETF Tools Development References: <545262C9.2070800@nostrum.com> In-Reply-To: <545262C9.2070800@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/FjgWjNfKsF80Dbsl6bMavLemdJ0 Subject: Re: [TOOLS-DEVELOPMENT] Next steps on the rfc format related SoWs X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:28:54 -0000 I haven't gotten any feedback on this message. Should I combine idnits, rfclint, and svgcheck into one SoW, or leave them as separate things? Pros: Might build a work bite large enough to be interesting to more bidders Cons: Fatesharing separable problems As below, I think we must keep the publication formatter, xmldiff, and the text submission converter as separate things. Before I start in on combining any of the SoW, I'd like to hear that this group still thinks that's the right thing to do. RjS On 10/30/14 11:09 AM, Robert Sparks wrote: > For reference - these are the documents in flight: > PublicationFormatter-02 > TextSubmissionConverter-02 > idnits-00 > rfclint-04 > svgcheck-02 > xmlDiff-03 > > The next burst of effort needs to focus on fleshing out > PublicationFormatter, > and making sure the documents from the rfc-design team that it points > to are > sufficiently clear to inform implementation. > > We've talked for some time about combining some of these near the end. > We're > getting there, and I want to double check what we think should be > combined to > reduce the number of SoWs. > > I can see combining idnits, rfclint, and svgcheck into one SoW (that > asks for three tools). > > I'm not sure we want to couple the fates of any of > xmlDiff, TextSubmissionConverter, and PublicationFormatter. > > Is having four SoWs when we're done the right target? > > RjS > From nobody Mon Nov 24 08:37:07 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA22F1A86F8 for ; Mon, 24 Nov 2014 08:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-lOG3jeQi3B for ; Mon, 24 Nov 2014 08:37:03 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 967291A86F3 for ; Mon, 24 Nov 2014 08:37:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 3EAE1B010A3; Mon, 24 Nov 2014 11:38:07 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUMTxI1r9JBT; Mon, 24 Nov 2014 11:38:06 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 75624B01087; Mon, 24 Nov 2014 11:38:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Scott O. Bradner" In-Reply-To: <54735CBB.4000301@nostrum.com> Date: Mon, 24 Nov 2014 11:37:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50F8D28F-CACE-4AF2-AF1F-8DCA3873A32F@sobco.com> References: <545262C9.2070800@nostrum.com> <54735CBB.4000301@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/deBZydOws1l0LyGEcKxhZ_DbYh0 Cc: IETF Tools Development Subject: Re: [TOOLS-DEVELOPMENT] Next steps on the rfc format related SoWs X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:37:06 -0000 fwiw - combining the smaller jobs seems reasonable to me Scott > On Nov 24, 2014, at 11:28 AM, Robert Sparks = wrote: >=20 > I haven't gotten any feedback on this message. >=20 > Should I combine idnits, rfclint, and svgcheck into one SoW, or leave = them as separate things? >=20 > Pros: Might build a work bite large enough to be interesting to more = bidders > Cons: Fatesharing separable problems >=20 > As below, I think we must keep the publication formatter, xmldiff, and = the text submission converter as separate things. >=20 > Before I start in on combining any of the SoW, I'd like to hear that = this group still thinks that's the right thing to do. >=20 > RjS >=20 > On 10/30/14 11:09 AM, Robert Sparks wrote: >> For reference - these are the documents in flight: >> PublicationFormatter-02 >> TextSubmissionConverter-02 >> idnits-00 >> rfclint-04 >> svgcheck-02 >> xmlDiff-03 >>=20 >> The next burst of effort needs to focus on fleshing out = PublicationFormatter, >> and making sure the documents from the rfc-design team that it points = to are >> sufficiently clear to inform implementation. >>=20 >> We've talked for some time about combining some of these near the = end. We're >> getting there, and I want to double check what we think should be = combined to >> reduce the number of SoWs. >>=20 >> I can see combining idnits, rfclint, and svgcheck into one SoW (that = asks for three tools). >>=20 >> I'm not sure we want to couple the fates of any of >> xmlDiff, TextSubmissionConverter, and PublicationFormatter. >>=20 >> Is having four SoWs when we're done the right target? >>=20 >> RjS >>=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development From nobody Mon Nov 24 09:26:04 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486B51A700E for ; Mon, 24 Nov 2014 09:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN5mVsCaXVtp for ; Mon, 24 Nov 2014 09:25:58 -0800 (PST) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29881A6FFF for ; Mon, 24 Nov 2014 09:25:58 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id sAOHPtWT004344 for ; Mon, 24 Nov 2014 09:25:58 -0800 Received: from tonys-macbook-pro.local (unknown[135.110.241.227](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20141124172553gw100r93m6e>; Mon, 24 Nov 2014 17:25:55 +0000 X-Originating-IP: [135.110.241.227] Message-ID: <54736A20.9040406@att.com> Date: Mon, 24 Nov 2014 12:25:52 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Tools Development References: <545262C9.2070800@nostrum.com> <54735CBB.4000301@nostrum.com> In-Reply-To: <54735CBB.4000301@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/fW_3w9O_F61_070NDoNlWaCQMD0 Subject: Re: [TOOLS-DEVELOPMENT] Next steps on the rfc format related SoWs X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:26:00 -0000 An alternative to combining the SoWs, but slightly harder to manage up front, is to either 1) allow people to bid in lots, or 2) add a "combination SoW" that includes the ones you want to combine via reference. Tony On 11/24/14, 11:28 AM, Robert Sparks wrote: > I haven't gotten any feedback on this message. > > Should I combine idnits, rfclint, and svgcheck into one SoW, or leave > them as separate things? > > Pros: Might build a work bite large enough to be interesting to more > bidders > Cons: Fatesharing separable problems > > As below, I think we must keep the publication formatter, xmldiff, and > the text submission converter as separate things. > > Before I start in on combining any of the SoW, I'd like to hear that > this group still thinks that's the right thing to do. > > RjS > > On 10/30/14 11:09 AM, Robert Sparks wrote: >> For reference - these are the documents in flight: >> PublicationFormatter-02 >> TextSubmissionConverter-02 >> idnits-00 >> rfclint-04 >> svgcheck-02 >> xmlDiff-03 >> >> The next burst of effort needs to focus on fleshing out >> PublicationFormatter, >> and making sure the documents from the rfc-design team that it points >> to are >> sufficiently clear to inform implementation. >> >> We've talked for some time about combining some of these near the >> end. We're >> getting there, and I want to double check what we think should be >> combined to >> reduce the number of SoWs. >> >> I can see combining idnits, rfclint, and svgcheck into one SoW (that >> asks for three tools). >> >> I'm not sure we want to couple the fates of any of >> xmlDiff, TextSubmissionConverter, and PublicationFormatter. >> >> Is having four SoWs when we're done the right target? >> >> RjS From nobody Sun Nov 30 07:47:18 2014 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA951A0377 for ; Sun, 30 Nov 2014 07:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBm4gc5IlisV for ; Sun, 30 Nov 2014 07:47:15 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 77A8E1A0370 for ; Sun, 30 Nov 2014 07:47:15 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E134E9A4002; Sun, 30 Nov 2014 10:47:04 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id UuAwT4dbYL0b; Sun, 30 Nov 2014 10:47:04 -0500 (EST) Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2F9719A4001; Sun, 30 Nov 2014 10:47:04 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Nov 2014 10:46:52 -0500 Message-Id: <59F718A1-BA2A-4962-84AB-11AA36EE0214@vigilsec.com> To: IETF Tools Development Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tools-development/WMSGaK5MlRka2lhWyHGz3ATtFf0 Cc: Joe Hildebrand Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 2 December 2014 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 15:47:17 -0000 Tools Call Agenda -- 2 December 2014 at 13:00 Eastern 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik - IPR Tool improvements -- Robert - Liaison Tool improvements -- Robert 2. Community & Other Projects - Present a directory view of active, archived, and unknown I-Ds -- AMS - Mentor Support Tool -- AMS - IETF Website Makeover -- Joe and Greg 3. RFC Services Projects - xml2rfc bug fixes -- Alice and Henrik - DOI RFP -- Ray - RFC Editor Website Makeover RFP -- Ray - Automatic stats and reporting RFP -- Ray - rfclint SOW -- Robert - text submission converter SOW -- Robert - RSE's Design Team -- Heather 4. Transition of Mission Critical Tools - Moving mail aliases to ietf.org and link them to datatracker database - Moving issue trackers and wikis for IETF WGs on ietf.org 5. Server Infrastructure - VM Architecture for Servers -- AMS - iCal servers -- AMS - IMAP access to the email archives -- Robert 6. IDIQ Contractors - Status of RFP for more IDIQ contractors -- Ray 7. Parking Lot - Test Coverage -- Henrik 8. AOB