[
Lists Home |
Date Index |
Thread Index
]
I'd like to correct a misperception on what I thought I said. I see two
types of potential specialization activity; one concerns the TC directly,
such as whether to posit a more general ancesor to task (a change or update
to the scope of DITA's core specification), the other are the community
activities that the TC becomes involved with only to the extent of
providing guidance or certification of some sort. I would expect the DITA
Wiki to be the natural place in which communities of interest can
colloborate to evolve their particular specializations, using whatever
process or page model suits them. But the Wiki tool is not enough--a
specialization community might also need a mailing list and file-upload
capability. These things will happen in time. The expedient thing is to
get the Wiki launched so that the germination of ideas can begin.
I did try to point out the OASIS policy that TC-related development itself,
such as core-level specializations, should occur only within theTC's own
collaborative resources on oasis-open.org. But I absolutely see the DITA
Wiki as the environment for creating the specialization communities for
training/education, for handset and semiconductor domains, for parts
description, and more. Mary and her OASIS team seem very interested in
making certain that dita.xml.org has the services that will support this
sort of activity.
Regarding module and term registries, shouldn't those be discussed first by
the DITA TC? The charter declares the specialization registry as in the
TC's purview, so perhaps the TC should be given the chance to step up to
create long-term management for modules and terms as well. If the TC
agrees to give these back to the public, then the DITA community can create
the open source process for these artifacts of community design effort,
which may well end up at the DITA Wiki.
Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-838-8550
T/L: 678-8550
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
"Esrig, Bruce
(Bruce)"
<esrig@lucent.com To
> "'mary.mcrae@oasis-open.org'"
<mary.mcrae@oasis-open.org>,
10/17/2005 04:49 dita-fa-edboard@lists.xml.org
AM cc
Subject
RE: [dita-fa-edboard] dita.xml.org
services
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)
a. ideally a real online web form (click/submit) [+/-]
b. fields for: data genre, suggested URI location for the added
data, descriptive text, submitter email address, relevant URIs
[+]
c. supports designation of usage: content by reference vs literal
content submission [+]
d. 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
a. Create the domain "dita.xml.org" and ensure that it is
accessible in all browsers. (IT)
b. Create content for a placeholder page describing the focus
area, how to participate, and planned launch date (CG)
c. Upload the content to dita.xml.org. (IT)
3. Create dita.xml.org wiki
a. Determine the location for the dita.xml.org wiki (IT)
b. Place the wiki at dita.xml.org/wiki/ (IT)
c. Create content for a placeholder page describing terms of use,
how to use, etc. (CG)
d. Upload the content to dita.xml.org/wiki/ (CG/MM)
4. Look and Feel
a. Work with designer to create an overall look and feel for the
focus areas (CG)
b. Work with the Editorial Board to determine necessary
refinements (CG, MM, EdBd)
c. Create stylesheets for portal pages and wiki (IT, MM, RC)
d. Upload/implement stylesheets (IT)
5. Evaluation, selection and implementation of web publishing and
wiki engines
a. Per defined requirements; consideration given to extended
toolset for additional functionality and historical performance
(development cycles, enhancements, stability, etc.) (IT, Staff)
b. Install all necessary software (IT)
c. Provide testbed to staff, editorial board (IT)
d. Test (IT, Staff)
6. Aggregate Content for Focus Area
a. Aggregate content for portal (EdBd)
b. Aggregate SIG/UG info for wiki
c. Determine other content zones for wiki
Launch
7. Portal Page(s)
a. Initial content prepared by Editorial Board and uploaded by
staff
b. Implementation of web publishing system to support Editorial
Board creation/maintenance of future pages
8. Wiki
a. Initial content prepared and uploaded by Editorial Board
b. Rollout to SIGs/UGs and end users
9. Announcements
a. Press releases
b. OASIS Member news
c. Websites
d. Cover Pages
Launch + (actual timeline to be determined)
10. Forum
a. Pre-define forum focus areas (EdBd)
b. Determine migration path for existing content
c. Announce forum to dita-users@yahoo
11. Calendar
a. Define calendar metadata requirements (EdBd)
b. Implement calendar system (IT)
c. Pre-populate known events (EdBd)
d. Announce calendar
|
