Specification format rules

["Scott Cantor" <cantor.2@osu.edu>]

I took an action to read over the process rules around document formatting.

The relevant section is here:
http://www.oasis-open.org/committees/process.php#2.18

The only section that directly deals with the XHTML issue is this:

"Editable formats of all versions of TC documents must be submitted 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 submitted to the TC's document repository in the editable source, XHTML,
and PDF formats. Any links published by the TC shall be to the XHTML and/or
PDF formats stored using repositories and domain names owned by OASIS and as
approved by the TC Administrator."

Since my definition of XHTML is that it's valid, I don't really see this as
an enforced policy based on my review of other TC deliverables. I would
conclude that best effort is about all they're trying to get, and we may
need to decide whether readability trumps validity unless we start using
docbook.

The last sentence seems to vaguely refer to the whole "persistent link"
issue and the permanent document tree outside Kavi. Doesn't seem to suggest
there's much process yet around organizing that tree.

Also, FYI, as of June 1, this clause takes effect:

"A specification that is approved by the TC at the Public Review Draft,
Committee Specification or OASIS Standard level must include a separate
section, listing a set of numbered conformance clauses, to which any
implementation of the specification must adhere in order to claim
conformance to the specification (or any optional portion thereof)."

I would suggest that if we expect to produce any further profiles, that we
come to some decision about how to structure that, and I would further
suggest that conformance ONLY be possible with respect to a standard AND its
errata as of a certain date. This makes it impossible for a normative errata
change to affect conformance, thus sidestepping the current definition of
errata in the TC process.

I might even argue we should consider revising the SAML standard's overall
conformance document and resubmitting the SAML standard so that actual spec
maintenance becomes possible.

-- Scott