[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [coel] OASIS documents overview
Chet Many thanks for your email – all very useful. Regards Joss Important Information: The contents of this email are intended for the named addresses only and contain information which is confidential and which
may also be privileged. Unless you are the named addressee (or authorised to receive for the addressee) you may not copy, use it, or disclose it to anyone else. If you received it in error, please notify us immediately at
enquiries@activinsights.co.uk and then destroy it. Further, whilst we make efforts to keep our network free from computer viruses, etc., you do need to check this email and any attachments to it for viruses
as we can take no responsibility for any viruses which might be transferred by way of this email.
Activinsights Limited, Unit 11, Harvard Industrial Estate, Kimbolton, Cambs, PE28 0NJ. A company registered in England & Wales. Registered number:
06576069 From: coel@lists.oasis-open.org [mailto:coel@lists.oasis-open.org]
On Behalf Of Chet Ensign Hi Joss, I can give you some feedback on these questions. On Fri, Sep 25, 2015 at 9:25 AM, Joss <Joss@activinsights.co.uk> wrote: For all documents ·
How relevant is the date at the top of page 1 and in the footer? For your working drafts, it isn't critical. It is simply whatever date you want to use to indicate when the draft was written or completed. When we publish your approved work - e.g. when you release it for public review - we set this to
the date the TC approved the document. So, for example, if the TC approved a motion to submit the document for public review at its Sept. 25th meeting, that is the date we would put there.
Yes that's fine. The additional artifacts section is just to list any other components, such as schemas, that are part of that specific specification. If a specification document is complete and has no other pieces that go with it, then
you can make it none so that, when we publish it, we will know not to look for anything else to go with it.
Yes - I would list out all the related specifications there.
On the front page of the spec, we will do that when we publish them. We use the Latest Version links since those always point to the most up to date version of the spec. See how this is done in the KMIP spec:
http://docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html The template you are working in should have both the "This version" link and the "Latest version" links for each document. Note that these are the locations where the documents *will* be published so those links will not work until we have
published your work the first time around. For normative and non-normative references in the body of the spec, you'll need to check links yourselves.
On references generally, please note that the requirement for them is that any external content you cite in the body of the spec needs to be listed here. So for example if you cited to Key Management Interoperability Protocol Specification
Version 1.2 for some reason in the body of the document in a section on security (just making this up of course), then you would include the reference in the references section. There is no need to list references that aren't mentioned in the body of the specification. Certainly, nothing should appear under Normative References that isn't used elsewhere in the spec since, by making it Normative, you are in essence
saying that people implementing your spec will also need to use some or all of the Normatively referenced spec.
Nope, we don't have any governing styles on these.
If you do use the track change feature, I ask that you accept all changes in the working draft that the TC approves as a Committee Specification Draft. I sometimes get drafts with the change tracking still turned on and then I have to accept
all the changes and I hate doing that myself because then what if something is wrong there? Then it looks as if I messed the spec up in publishing it. Likewise, I recommend removing any comments embedded in the draft since they will go out with the publication.
(I do not remove comments.) Let me know if you have any questions on any of this... /chet
--
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]