[rfc-i] draft-iab-html-rfc-02: references

Julian Reschke julian.reschke at gmx.de
Tue Mar 1 09:50:03 PST 2016


On 2016-03-01 18:37, Paul Hoffman wrote:
> On 1 Mar 2016, at 9:26, Julian Reschke wrote:
>
>> So yes, it needs to be documented.
>
> More than that: it needs to be implemented the same way for every output
> formatter. So far, we have achieved that though the prep tool creating
> XML that the output formatters can use directly instead of having to
> apply additional checks.
>
>> Right now I'm concerned about authoring and formatters, not the preptool.
>
> If you are concerned about the formatters, you would want them to
> receive something they could not get wrong.

Motherhood and apple pie. I also want to avoid additional complexity 
that every formatter will otherwise have to implement.

>> If I understand your proposal correctly you propose that the old
>> format continues to be ok, but there'll be another way of doing
>> things, that'll be output by the preptool, and that any formatter will
>> have to understand. That makes things worse (IMHO), because there are
>> now *two* ways to achieve the same thing -- you can't fix a complexity
>> problem by adding more complexity.
>
> It feels like you have forgotten that the output formatters will be
> using the output of the preptool. If you had remembered that, your last
> sentence would not make sense.

I think you're making assumptions about formatters that may not be 
correct. For instance, *I* am maintaining a formatter (and plan to 
support V3), but I'll not be able to rely on the preptool (for entirely 
technical reasons).

We may have terminology problem.

For me a "formatter" is something that takes the user's V3 source and 
generates output from that. You seem to propose a formatter that does 
two passes, a preparation pass and a formatting pass. That's an entirely 
fine way to implement the formatting (and yes, the prep stage is needed 
to get the canonical format for archival), but it's not the only way to 
implement things.

Best regards, Julian




More information about the rfc-interest mailing list