Document process / FLE's slate on the Experience document
Folks, firstly, here's FLE's fist take on the Experience document. Secondly, and that's what this mail is mainly all about, I had a chat with Greg Newby about the documents process regarding ByteIO. As a summary, our situation is kind of special, because during the Interop test, we found issues that made us change the XML renderings for the specification to ensure interoperability. No doubt there are groups in OGF and elsewhere that may be in th the same situation when they do interoperability, but the point is that the current OGF documents process has a definition hole for this situation. After a longer discussion with Greg we agreed that this needs fixing in the revision of GFD.1 which is currently in public comment, and that Greg will address that. The consequences for us are hence as follows. 1) We still need to return the Interoperbility document t GFSG with changes coming from the PC period. I will take care of that. 2) The Experience document we are writing at the moment will go through its own PC period as normal. How ever, this document will explicitly mention and document that as a result of the interop tests, we had to change the XML rendering for the Specification, hence obsoleting the relevant appendices of the Functional Spec and the WSRF rendering, where appropriate, The document then will also explicitly mention that the online version of the XML and WSDL will reflect the latest version of the XML and WSDL. 2.1) We therefore need to add a chapter to the Experience document that describes the changes to the XML and WSDL as outlined above. THat way, we update the spec without having to go through the fairly heavyweight process of a new set of requirements documents. Cheers, Michel
Hi Michel,
Secondly, and that's what this mail is mainly all about, I had a chat with Greg Newby about the documents process regarding ByteIO.
[...]
2) The Experience document we are writing at the moment will go through its own PC period as normal. How ever, this document will explicitly mention and document that as a result of the interop tests, we had to change the XML rendering for the Specification, hence obsoleting the relevant appendices of the Functional Spec and the WSRF rendering, where appropriate, The document then will also explicitly mention that the online version of the XML and WSDL will reflect the latest version of the XML and WSDL.
2.1) We therefore need to add a chapter to the Experience document that describes the changes to the XML and WSDL as outlined above. THat way, we update the spec without having to go through the fairly heavyweight process of a new set of requirements documents.
Well, that is interesting. But how is a consumer of the ByteIO spec to find out that the original spec document is actually outdated, and that the new updated spec is found in the appendix of the Experience document? Andre.
Cheers, Michel -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Hi Andre, On 15 Oct 2007, at 16:30, Andre Merzky wrote:
Hi Michel,
Secondly, and that's what this mail is mainly all about, I had a chat with Greg Newby about the documents process regarding ByteIO.
[...]
2) The Experience document we are writing at the moment will go through its own PC period as normal. How ever, this document will explicitly mention and document that as a result of the interop tests, we had to change the XML rendering for the Specification, hence obsoleting the relevant appendices of the Functional Spec and the WSRF rendering, where appropriate, The document then will also explicitly mention that the online version of the XML and WSDL will reflect the latest version of the XML and WSDL.
2.1) We therefore need to add a chapter to the Experience document that describes the changes to the XML and WSDL as outlined above. THat way, we update the spec without having to go through the fairly heavyweight process of a new set of requirements documents.
Well, that is interesting. But how is a consumer of the ByteIO spec to find out that the original spec document is actually outdated, and that the new updated spec is found in the appendix of the Experience document?
Actually, the original spec is not the final spec. What we have is a *proposed* recommendation, though expected to be pretty stable. But there's got to be a process for cases like ours which I think is not or will not be so uncommon. The detailed process is actually not really fixed, and if you have time please comment on that in the current PC for GFD.1. Cheers, Michel
Thanks for the clarification - yep, I'll comment on GFD.1 :-) Cheers, Andre. Quoting [Michel Drescher] (Oct 15 2007):
To: Andre Merzky
Hi Andre,
On 15 Oct 2007, at 16:30, Andre Merzky wrote:
Hi Michel,
Secondly, and that's what this mail is mainly all about, I had a chat with Greg Newby about the documents process regarding ByteIO.
[...]
2) The Experience document we are writing at the moment will go through its own PC period as normal. How ever, this document will explicitly mention and document that as a result of the interop tests, we had to change the XML rendering for the Specification, hence obsoleting the relevant appendices of the Functional Spec and the WSRF rendering, where appropriate, The document then will also explicitly mention that the online version of the XML and WSDL will reflect the latest version of the XML and WSDL.
2.1) We therefore need to add a chapter to the Experience document that describes the changes to the XML and WSDL as outlined above. THat way, we update the spec without having to go through the fairly heavyweight process of a new set of requirements documents.
Well, that is interesting. But how is a consumer of the ByteIO spec to find out that the original spec document is actually outdated, and that the new updated spec is found in the appendix of the Experience document?
Actually, the original spec is not the final spec. What we have is a *proposed* recommendation, though expected to be pretty stable. But there's got to be a process for cases like ours which I think is not or will not be so uncommon.
The detailed process is actually not really fixed, and if you have time please comment on that in the current PC for GFD.1.
Cheers, Michel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
participants (2)
-
Andre Merzky
-
Michel Drescher