[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Use Case:] PFC
> > Ken Yagen wrote: > > > > SAML format is here: > > > http://www.oasis-open.org/committees/security/docs/draft-sstc- > doc-guidelines-02.txt > > > > I believe the above guidelines were amended though to accept word > > files as acceptable for documents instead of requiring XML documents > > for everything. Also, JPEG is acceptable for images, but > Powerpoint is > > required if any editing of the image will be needed. > > ok. i think we have reached the point where we need buy-in by > the group > to proceed here. neither of these is non-trivial and i don't > think that > everyone in our group uses ms products (noticed the os/apps on > pierangela's laptop :o) to date i have seen a lot of text and > pdf files. > personally, i have a predilection towards open standards but i am > flexible (sounds like one of those weird, contradictory monty > pythonesque statements.) In SAML we started out with idea that we would do everything in XML, but a little to my surprise, the experts investigated and concluded this is not currently feasible, at least with free or inexpensive tools and perhaps not even with expensive ones. The reality in most of corporate America is that when you show up they give you Word. If you want to generate .pdf you need to go through a small or large amount of pain to get it. The position we have reached in SAML is that there is a Word template most people are using, although I am sure a submission in plain text would not be refused. At least one person has the ability to generate .pdf from Word files and thus, those who wish to read documents in a non-Microsoft format may do so. [I am probably going to regret saying this and I certainly have no desire to be a Microsoft apologist, but it seems to me that in practice there's not much to choose. There are free readers available for both Word and PDF. Creating either requires the purchase of an expensive tool from essentially one vendor. True the PDF format is published, but this makes little practical difference to most folks. ] > > > Also, I don't see > > it listed in here, but I think it is a good idea to include line > > numbering in the formatting of the document to ease discussion. > > good idea. will incorporate. is it acceptable to limit line > numbering to > the actual use case description field (aka 'Process Flow') or > do we need > to apply it to the whole document? No, it is important to number the entire document. The point is to be able to refer to lines in suggesting revisions or clarifications to the document. Otherwise you end up saying "the 2nd sentence in the 3rd paragraph folowing..." > > > Regarding change history, I don't think it needs to be burdensome or > > overly complicated, but it is good to know why some types of changes > > are made. General editing and formatting don't have to be detailed, > > but the finalized use case could end up dramitically different from > > the original submission and it would help to know why significant > > changes were made. Having it in the document, I feel is > better because > > it is available to the reviewer to read and understand and keeps us > > from having to set up an external revision control system. > > understood. would like to get some feedback from others in > the group on > this, tho. In SAML there was a vote by the subcommittee one each usecase. Only things with 75%+ of the vote were "recommended" to the TC. In some cases, authors altered their usecase in order to attract sufficient votes. Once voted, usecases did not change. Under this model, change history does not make that much sense. Usecases are either 1) proposed, 2) accepted or 3) rejected. This is different from the specificfation which should have change history. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC