OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [cmis] Spec formatting

1. Actually, the use of line numbers in specifications is a forgotten
practice, used back when it was hard but it was the printer who had to do
it, not some desktop-publishing software.  I worked on ANSI X3.4
specifications in the 60s that had marginal line numbers.  I don't think I
have any copies left though.  

2. I have no quarrel with the omission of line numbers in XHTML documents,
where pagination is also not used, but that does make the use of permalinks
all the more valuable.

3. [Off-topic: The best place for line numbers to be useful is when a PDF is
the authoritative text.  For office-document formats the line numbers are
not authoritative (and neither is the document, really) because the
pagination and numbering can differ from one computer to another, and one
version/platform/configuration of the software to another (leading to a
variety of fidelity issues).  I do not think [X]HTML of lengthy texts or
ones in multiple pages are a good idea, unless a downloadable complete
version is also provided.  There are fidelity issues between different user
agents and it is important to be able to use the document reliably in an
off-line situation, including printed on paper.  That pretty much makes the
default choice a PDF at the current state of our technology.

You cannot believe how many man hours were wasted on the just-issued ODF 1.0
Errata 01 document because of problems counting lines, applying changes to
the wrong, but similar, place, etc.

4. [Agreement [;<) I enthusiastically agree with Robin Cover that having
finer granularity for section and even paragraph numbering will also do the
job.  Either way permits annotation of implementations, conformance reports,
and other artifacts (sermons included) by precise reference to appropriate
passages of the specification.  I accept the spirit of that completely.

 - Dennis

PS: Robin, Thanks for the quote on what must be delivered from the TC.  It
answers a question about schemas that I have over on another TC. 

-----Original Message-----
From: Robin Cover [mailto:robin@oasis-open.org] 
Sent: Monday, January 12, 2009 09:23
To: Dennis E. Hamilton
Cc: 'David Nuescheler'; 'Julian Reschke'; cmis@lists.oasis-open.org
Subject: RE: [cmis] Spec formatting

NB. "** Disclaimer" at the end of the message

"the published form of the specification needs printed line numbers..."

[ ... ]

* As far as I know, the idea os using line numbers in specs
   is a recent "innovation" -- oddly, because we have had the
   technical ability to print line numbers for decades.

[ ... ]

   In summary: while the topic of line numbering for specs could be debated,
   I think everyone agrees that a specification becomes clearer
   and easier to use when the (sub)sections are finely granulated,
   and provided with machine-readable (URI-addressable, linkable) anchors
   for hypertext navigation.  This memo has been written chiefly to
   encourage good document design which does not depend upon line
   numbers for citation.

[1] http://www.oasis-open.org/committees/process-2008-06-19.php#specQuality


Editable formats of all versions of TC documents must be
delivered to the TC's document repository. TC Working
Drafts may be in any format (i.e. produced by any application).
All TC-approved versions of documents (i.e. Committee Drafts,
Public Review Drafts, and Committee Specifications) must be
delivered to the TC's document repository in the (1) editable
source, (2) HTML or XHTML, and (3) PDF formats; and the TC
must explicitly designate one of those delivered formats as
the authoritative document. Any links published by the TC
shall be to the HTML, XHTML and/or PDF formats stored using
repositories and domain names owned by OASIS and as approved
by the TC Administrator.

All schema and XML instances, whether by inclusion or by
reference, including fragments of such, must be well formed.
All expressions must be valid. Each schema and XML instance
that is part of the specification must be delivered in its
own separate plain text file.

** Disclaimer: this memo is not official OASIS guidance; it's just a
personal (but studied) opinion by an OASIS Staff members speaking
for himself as an individual, not for OASIS Staff.


  - Robin Cover

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783

[ ... ]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]