[rfc-i] [IAB] draft-iab-xml2rfc-03, "2.19 <displayreference> "

julian.reschke at gmx.de (Julian Reschke) Wed, 02 March 2016 18:09 UTC

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 2 Mar 2016 19:09:25 +0100
Subject: [rfc-i] [IAB] draft-iab-xml2rfc-03, "2.19 <displayreference> "
In-Reply-To: <B3320A0F-01F7-47CB-9DB1-0384FD0329E3@cisco.com>
References: <56D607FC.4070903@gmx.de> <40F98072-B8FE-48D7-A506-946558ACB9D6@cisco.com> <56D688F7.5060508@gmx.de> <7F5B319D-106C-4928-8B48-88F9D3A3CF99@cisco.com> <EED7D730-19DD-4A4B-BAAA-B43C9706CB0B@vpnc.org> <56D71133.2070104@gmx.de> <3963CC28-58A0-4B88-8C51-CDD850A2A962@cisco.com> <56D7189D.7080402@gmx.de> <08AA6C20-8EE8-4930-9061-29290F996DBD@cisco.com> <56D71D1D.2070101@gmx.de> <B3320A0F-01F7-47CB-9DB1-0384FD0329E3@cisco.com>
Message-ID: <56D72C55.7060401@gmx.de>

On 2016-03-02 18:14, Joe Hildebrand (jhildebr) wrote:
> ...
>>> I disagree.  Once a document comes out of the preptool, there's *exactly* one place to get all of those bits of information.  That's the whole point of the preptool, is to refactor a bunch of logic that would otherwise have to be in all of the output formatters.
>>
>>  From the preptool's point of view, maybe.
>>
>> However, other formatters (such as mine) will now have to deal with two
>> places this information can come from.
>
> Then your formatter is acting as it's own preptool.  If you ran the preptool on your inputs first, your output formatter would get a good deal smaller.

As I said, that's not always possible.

> Anyway, I really don't want to revisit the whole idea of the preptool at this point, unless you want to propose a full system that would not require it.  We've been working with this approach for a couple of years, and it seems to be a good fit for the requirements.

I have no problem with a preparation stage in itself. But I feel it 
becomes a problem when it creates unneeded complexity.

>  ...

Best regards, Julian