[rfc-i] Pagination requirements

Joe Touch touch at isi.edu
Fri May 25 23:34:18 PDT 2012

On May 25, 2012, at 11:22 PM, Joe Hildebrand wrote:

> On 5/26/12 12:13 AM, "Joe Touch" <touch at isi.edu> wrote:
>> Why should I think about that code? Why is that ever needed except to edit?
> Because I asked nicely?  Because we're having a technical discussion, where
> implementation complexity is a relevant design parameter?

You're adding a requirement to the submission format that has not been shown. That requirement limits the author formats, without demonstrated necessity.

>> That is definitely NOT a presentation or navigation issue. It is thus out of
>> scope for as a requirement for the submission format, I claim.
> I reject that claim.  If the Editor is going to generate multiple output
> formats from the submission format, the submission format must be easy to
> handle programmatically.

Sure, but that alone does not justify the need for containment. Containment is needed for *editing*, not necessarily for generation.

> As such, presentation and navigation are secondary
> issues for the submission format, and are only at relevant in the case where
> the submission format is one of the output formats (as would be possible
> with HTML).

Presentation and navigation need to be able to be generated from the submission format. I assume that means they need to be present in that format.

The same is not true for editing information.

>>>> It has nothing to do with
>>>> containment unless containment is retained across reuses - which it likely
>>>> will not be. 
>>> I really don't understand that statement.  Why would the containment change
>>> over time?  Once the file is published, it's immutable.
>> Your need for code is a need to support reuse after it's published in a new
>> doc. I contend that this support for reuse is not - and should not be - a
>> requirement.
> Oh, you mean that you don't want to be able to retrieve information from the
> published document easily.  I think that's short-sighted, particularly if we
> can provide the capability with relatively little overhead.

The published document should probably support cut and paste - but there's no reason that needs containment. There's absolutely no motivation for being able to grab text without headers (the only example provided thus far) except as an exercise in oblique editing techniques.


More information about the rfc-interest mailing list