OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Forwarded comment for DITA 1.1 - 2



Hello,

I recommend you remove any reference to ditaval and "profiling" from
the 1.1 definitions.  That's implementation stuff, not relevant to a
standard definition.

I also recommend you strike mention of "conditional processing" from
the arch. spec.  *All* processing is conditional.  A language spec
should not be a tutorial on filtering or other processing - you can
assume the audience understands that stuff.  Labeling one subset of
attributes as "conditional" - sounds to me like it reflects the
language of the dita-ot implementers; not necessarily wrong or bad,
but it shouldn't be in a language definition.

In fact I would strike chapter 4 in toto and redistribute its contents
elsewhere.  A chapter on metadata might be a good replacement;
attributes like "platform" and "audience" are just metadata.  The spec
should not make unenforceable stipulations regarding how dita docs
should be used in general nor how such attributes should be processed
specifically.  In my view the spec should simply state the intended
semantics as concisely as possible, no more and no less.

By the same token, I don't see any problem with publishing a
non-normative Guide that sums up common practices and explains how
DITA was designed to suit those practices.  But the Standard doc
itself should be minimal.  As it stands now, the Arch. spec is a mix
of user guide, language definition, and tutorial.  Don't get me wrong,
it's not bad now, but I think it could be better.  You could probably
fully and precisely define the Arch. in less than ten pages.  Not only
would that make for a more useful spec. document, I think it would
lead to a better "Guide to DITA" document.

Sincerely,

Gregg Reynolds

This publicly archived list offers a means to provide input to the
OASIS Darwin Information Typing Architecture (DITA) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: dita-comment-subscribe@lists.oasis-open.org
Unsubscribe: dita-comment-unsubscribe@lists.oasis-open.org
List help: dita-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/dita-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita



Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Blue Pages (Internal)

"Transparency and accessibility requirements dictate that public
information and government
transactions avoid depending on technologies that imply or impose a
specific product or
platform on businesses or citizens" - EU on XML-based office document
formats.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]