[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Specification format rules
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]