RE: [dita-fa-edboard] dita.xml.org services

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

Hi Mary,

 

Carol Geyer said that you have definite opinions on the content areas for the Wiki.

 

My hope was that we would be establishing development areas for certain specializations, and that they would reside within the Wiki using the paired-pages model. One page for results; a partner page for discussions. This clashes with a perspective that I heard from Don Day, in which the focus area would not be able to host specialization development; this was based in part on a perception that Wikis are not good for that. I am inquiring about that and also inquiring whether there are questions in your mind about whether to host such conversations on an OASIS-sponsored site.

 

It may have been an erroneous thought on my part, but I had connected, for example, the discussion of support-for-training with the establishment of this focus area, and had thought that this was a fortuitous meeting of a need with a potential solution. If the focus area will not be meeting the support-for-training need, then we will need to find another means of hosting those discussions.

 

A second specialization area that I was hoping would have some support was markup languages for handsets. If DITA were to be used directly as a handset content markup language, or as a source from which marked-up handset content could be generated, it would be helpful to have a forum in which to bring the relevant ideas together.

 

Aside from specializations, I was interested in one further service, and have since thought of a second one.

 

We've been talking about the need for a module registry, and the focus area seems to me to be an obvious place to put it. To register a module, the owner of a module would enter a module name, the names of the modules it depends on directly for supporting definitions, and the names and class inheritance structure of each introduced identifier. There is a question whether someone would be permitted to register a module without releasing the entire definition. Previous conversations about the module registry have included Robert Anderson of the DITA TC.

 

The new idea is of a term registry. The most primitive form of this would be a sequence number generator. A term is given a unique sequence number to identify its use in a particular sense. Those who use a term in their content have the option of getting a new sequence number, using an existing sequence number, or not getting a sequence number. Certain behaviors that are difficult to define without these numbers would become rather easy to define in their presence. So users of the sequence numbers would get predictable behavior when, for example, attempting to reuse content from outside an individual project.

 

Best wishes,

 

Bruce

-----Original Message-----
From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
Sent: Thursday, October 13, 2005 5:51 PM
To: dita-fa-edboard@lists.xml.org
Subject: [dita-fa-edboard] FW: dita.xml.org requirements document

Hello everyone,

 

  Below is the latest draft of the focus area requirements document. Please review and provide feedback by end of day, Monday Oct. 17. Thanks!

 

Mary

 

------------- 

DITA.xml.org Focus Area

Goals and Objectives

The overall goal of the DITA.xml.org focus area is to foster the use and further development of DITA by providing a single point of access for developers, implementers and end-users interested in the DITA architecture.

Objectives:

1. Create a web portal with access points to external information sets, mailing lists/forums, wikis, blogs, calendars, and other resources as defined by the editorial board.
2. Maintain a list of vendors providing products and services related to DITA.
3. Maintain a list of conferences, trade shows, seminars, training events and webinars related to DITA.
4. Maintain links to white papers, conference presentations, past webinars and other materials related to DITA.
5. Provide a wiki to be used to create "best practices", reference materials, information on local DITA SIGs/UGs.
6. Provide a calendar that can be used to view "at a glance" training sessions, webinars, conferences and presentations, user group meetings, and other related information.
7. Provide a forum for threaded conversations that are searchable.
8. Foster an environment that will attract new members to OASIS and the DITA TC to create DITA industry or task-specific specializations

Anticipated Usage:

1. Portal Page(s): This content will be created/maintained by members of the DITA Editorial Board and OASIS staff. Access must be restricted to authorized individuals only.
2. Wiki(s): The wiki will be divided into multiple areas, referred to as "content zones", as determined by the Editorial Board. For instance, it is anticipated that each local DITA Special Interest Group (SIG) or User Group (UG) would have their own "zone" within a larger zone dedicated to SIGs/UGs. Each content zone should have at least one individual who is responsible for maintaining the content and ensuring that any information deemed "inappropriate" is removed.
3. Calendar(s): A calendar to show at a glance when/where events are being held. The calendar should be viewable in the traditional layout; detailed information should be presented in a tabular fashion that can be sorted based on location, type of event, and any other information as determined by the Editorial Board.
4. Forum: The current dita users group is a yahoo group. The feature set supported by yahoo is much more robust when compared to the OASIS MLM lists. Providing a forum similar to that found at yahoo will attract the user community back to OASIS - where they have access to all the information they will need in a single location.
5. Other applications: As determined by the Editorial Board. Possiblities include blogs, polls, FAQs, Surveys, Newsletters, etc.

Must Have Features

1. The publishing system should support multiple authorized authors and editors.

2. Authoring/editing access to specific Focus Areas should be limited to authorized individuals (always includes designated OASIS staff).

3. GUI/WYSIWYG editing interface should be included.

4. "Push-button" self-publishing of authored/edited content should be supported.

5. Documents generated by the authoring/editing tool(s) must be DTD- or Schema-valid HTML 4.x or XHTML.

6. Internal document components (primary content objects) (DIVs, etc) must be directly "linkable" from/by other OASIS websites using URI references; [thus, authoring tool must support creation of (X)HTML IDs/anchors].

7. Publishing architecture must support link persistence. That is: (a) links published via URI reference to internal website resources must be persistent links; (b) documents and document objects which have ID/anchors must provide stable, persistent reference targets [dereferenceability via DNS/HTTP] through time; (c) published linkable objects therefore do not disappear and links do not expire.

8. Authors must be able to create predictable URIs of their choice using single-case or mixed-case spelling from any of (at least) these characters: [A-Za-z0-9] plus PERIOD and HYPHEN, including fragment identifiers for relative references [this implies use of mixed-case in filenames as well as in the spelling of internal fragment identifiers]

9. Authors/editors must be able to upload disk files from remote locations (at least from their local machine) to the OASIS computer for use in the (X)HTML documents [for example, .GIFs and .JPGs]

10. (X)HTML documents created by the authoring/editing tool(s) must conform to industry best-practice standards implementation for media types and CSS, not depending upon browser-specific scripting languages, plugins, or similar features, and not critically dependent (for accessiblity/ usability) upon scripting languages that require the reader to enable scripting [thus: documents must be directly viewable in all standard/popular Web browsers].

11. The publishing system should have a reputation for robust security features, by architecture and by proven code quality, so as not to expose the host computer and other OASIS networked computers to security and privacy vulnerabilities.

12. Editors must be able to use any browser on any platform (Windows Mac, Linux, etc) for authoring/editing FA site content.

13. The system should not violate any (written or unwritten) OASIS privacy policies with respect to users viewing the documents in a web browser [thus, for example, the user should not be required to enable cookies].

14. The system should support/accommodate a publicly accessible content submission form, enabling users worldwide to submit recommendations for added site content, where "+" = required, "+/-" = optional (NB doesn't have to be native to the tool; can be built in connection with the tool)

1. ideally a real online web form (click/submit) [+/-]
2. fields for: data genre, suggested URI location for the added data, descriptive text, submitter email address, relevant URIs [+]
3. supports designation of usage: content by reference vs literal content submission [+]
4. upload staging area for literal submitted content that's not just descriptive text [+/-]

15. The publishing system must support the ability to revoke posting privileges to abusers of the system.

 

16. The publishing system must support the ability to move inappropriate posts to a quarantined area for consideration by the Editorial Board before removal.

 

17. The system should support the ability to create traffic reports for the overall focus area as well as on a page-by-page basis.

Highly Desirable Features

1. Customizable by OASIS (license + APIs allow)

2. Based upon open source code modules, ideally, ones that are currently in use at OASIS

3. Authors should be able to organize content (files) in a hierarchical system of their choice

4. Version rollback (similar to what we have with Moin Wikis)

5. Edit trail audit ("who edited this document?") -- usually comes with B.4

6. File locking (check-in/check-out)

7. Integrated support for Atom/RSS newsfeed

8. Notifications (notify authorized authors/editors and OASIS staff about website changes)

9. Raw (X)HTML editing mode as an option.

10. Ability to customize CSS code for individual pages

11. Search feature

Implementation Plan

Pre-Launch

1. Establish dita.xml.org editorial board

Establish an editorial board that will be responsible for providing and maintaining all content of the DITA.xml.org Focus Area in conjunction with OASIS staff.

2. Create dita.xml.org portal

1. Create the domain "dita.xml.org" and ensure that it is accessible in all browsers. (IT)
2. Create content for a placeholder page describing the focus area, how to participate, and planned launch date (CG)
3. Upload the content to dita.xml.org. (IT)

3. Create dita.xml.org wiki

1. Determine the location for the dita.xml.org wiki (IT)
2. Place the wiki at dita.xml.org/wiki/ (IT)
3. Create content for a placeholder page describing terms of use, how to use, etc. (CG)
4. Upload the content to dita.xml.org/wiki/ (CG/MM)

4. Look and Feel

1. Work with designer to create an overall look and feel for the focus areas (CG)
2. Work with the Editorial Board to determine necessary refinements (CG, MM, EdBd)
3. Create stylesheets for portal pages and wiki (IT, MM, RC)
4. Upload/implement stylesheets (IT)

5. Evaluation, selection and implementation of web publishing and wiki engines

1. Per defined requirements; consideration given to extended toolset for additional functionality and historical performance (development cycles, enhancements, stability, etc.) (IT, Staff)
2. Install all necessary software (IT)
3. Provide testbed to staff, editorial board (IT)
4. Test (IT, Staff)

6. Aggregate Content for Focus Area

1. Aggregate content for portal (EdBd)
2. Aggregate SIG/UG info for wiki
3. Determine other content zones for wiki

Launch

7. Portal Page(s)

1. Initial content prepared by Editorial Board and uploaded by staff
2. Implementation of web publishing system to support Editorial Board creation/maintenance of future pages

8. Wiki

1. Initial content prepared and uploaded by Editorial Board
2. Rollout to SIGs/UGs and end users

9. Announcements

1. Press releases
2. OASIS Member news
3. Websites
4. Cover Pages

Launch + (actual timeline to be determined)

10. Forum

1. Pre-define forum focus areas (EdBd)
2. Determine migration path for existing content
3. Announce forum to dita-users@yahoo

11. Calendar

1. Define calendar metadata requirements (EdBd)
2. Implement calendar system (IT)
3. Pre-populate known events (EdBd)
4. Announce calendar