이번 문서에서는 http://spring.zeroboard.com/prj_wiki/570428 에서 도출된 기본 기능을 바탕으로 각 기능별 상세내용을 정의합니다. 언제나 그렇듯, 모든 부분에서 의견을 환영합니다.

1. 하나의 문서를 여러사람이 편집

1.1. 복수의 사용자에게 편집권한을 준다.
- 모든 사용자에게 편집권한을 줄 경우 혼란이 예상된다.
   -> '편집권한의 제한' 참조
- 누가 수정했는지 표시할 수 있어야 한다.
   -> '버젼 히스토리'에 수정한 회원의 이름, 혹은 IP표시
   -> 페이지의 내용(Context)안에도 수정한 사람을 표기할 수 있도록
       -> 모니위키에서 @sig@를 문서의 내용안에 넣으면 수정한 사람의 사인(?)/이름이 표시된다.

1.2. 모든 위키 페이지에 edit버튼표시
- 디자인적인 고민 : '수정'버튼의 위치, 혹은 모양을 포함한 모든 UI에 대해서는 디자인적인 고민이 필요하다. 아울러, 위키모듈의 스킨또한 필요할 것으로 보인다.

2. 편집권한의 제한
2.1. ZBXE의 회원 권한시스템 이용
- 각 액션별로 회원그룹을 assign
- 위키모듈의 액션을 정의할 필요가 있다. (중요이슈)
- 위키모듈의 액션 정의 : 새 페이지 생성 / 페이지 수정 / 페이지 삭제 / 버젼히스토리 열람( view info, view diff) / 버젼히스토리 관리(일부삭제, 혹은 전체Purge) / 기타등등(도출되는데로 추가) / RSS / Trackback(2007. 9. 17. 변경)
  -> 위키모듈이 가져야 할 모든 액션을 도출할 필요가 있다. (2007. 9. 17. 추가) -별도의 기획이슈문서를 작성할 예정
  -> 위키모듈 하위의 모든페이지, 혹은 개별페이지 별 권한을 지정할 수 있어야 한다.
  -> ACL을 적용하고 있는 위키엔진의 경우 페이지의 이름을 기준으로 권한을 지정하기도 한다. 이것은 Wikiseed와 같이 위키를 이용하는데 필요한 페이지를 훼손(?)하는 경우가 있다. 최근 위키엔진들의 경향은 이것을 막는 것이다.

3. Access Violation 문제
- 제안문서에서 언급된 Lock 기능으로 해결.
- 기술적 문제는 개발그룹에서 처리. 
- 동시에 서브밋이 일어나지 않도록 앞에서 막아줄 필요가 있지 않을까?
- 이상론: 동시 서브밋이 일어나서 Access Violation이 발생했을때, 먼저 들어온 놈(?)을 적용하고 나중에 들어온 놈을 먼저 들어온 놈과 비교하여 merge하면 어떨까? 물론 나중에 들어온 놈에겐 merge를 승인 할 것인지, 어떤 부분이 다른지 보여줄 필요가 있을듯 싶은데? -> 되려 사용자에게 혼란을 야기시킬 수 있고 / 위키모듈 자체가 ZBXE의 입출력 루틴을 그대로 사용하기 때문에 구현상의 문제가 발생할 수 있을것으로 보인다.

4. 손쉬운 문서생성
- 위키모듈로 생성된 모든 위키 페이지에 '새 페이지 만들기' 버튼 표시 -> '모든 위키 페이지에 edit버튼표시' 참조
- 문서를 만든사람(편집한사람)의 표시 -> '버젼컨트롤' 참조'

이상 공동저작에 대한 기능의 상세내용을 정의하였습니다. 이 문서는 해당 기능에 대한 새로운 이슈가 생길때 마다 갱신될 예정이며, 상세내용의 정의가 완료된 후 새로운 이슈가 더이상 생기지 않을 때 문서의 수정이 더이상 되지 않음을 표시할 것입니다.

2007. 9. 14. 변경 - '동시편집'이라는 단어가 적절하지 않아서 '공동저작'으로 변경하였습니다.

2007. 9. 17. 변경 - RSS와 트랙백은 ZBXE의 코어에 해당하는 기능이며 별도의 ACL이 필요하지 않을것으로 보입니다. 단, RSS와 트랙백은 위키모듈의 기능액션 중 하나로 정의하고 위키문서 안에서 이것을 어떻게 활용할지에 대한 기획은 진행하기로 합니다.