I think there's a couple of questions:
- what do we provide as a downloadable
zip
- what do we provide as PDF
- what do we provide as HTML
At the start of this release, many of
us were concerned that the continued proliferation of specializations would
render DITA too intimidating for new adopters and tool providers. In particular,
it's hard to defend DITA as a simple but extensible architecture if we
have no downloadable documents that are less than 1000 pages long.
As a compromise between documenting
every possible DTD combination and documenting none of them, we agreed
on the following:
-
deliver and document a base set of DTDs with minimal domains and minimal
markup support. This was at one end of a continuum.
-
deliver and document two specific packages:
one roughly representing our existing
specialized markup, with extensions for machine industry semantics
and the other representing the major new specializations
for learning and training
As an additional compromise, we agreed
to provide the integrated HTML documentation for everything, while continuing
to provide separate PDFs for each package. This made sense inasmuch as
the PDFs needed to be chunked at a lower level for printability, whereas
the HTML needed to be cross-linked for navigability.
So, I think as it currently stands,
there are 3 zips, 3 PDFs, and 1 HTML web. I'd like to see the counterproposals
summarized like this as well, so I can get a clear idea of what we're choosing
between. Then hopefully we can take a look at what the result would be
for each choice - ie, take a look at some prototype docs in the different
formats to see how truly navigable they are, how big they get, etc.
But we can't keep revisiting the chunking
decision every few months until we release. At some point the decision
has to stick.
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
"Ogden, Jeff"
<>
08/24/2009 12:46 PM
To
<>, "Grosso,
Paul" <>, "dita" <>
cc
Subject
RE: [dita] problem with packaging of
glossaries [but not really]
I am still confused about what we are
talking about here and what specific problem we are trying to solve.
I asked earlier and was told that we were
talking about "packaging". That is, what .zip file holds
what. Is that what we are still talking about?
Placing subsets of components into separate
packages is just a convenience to allow people to download something less
than everything. But since this seems to be causing so much controversy/confusion,
perhaps we should abandon the idea of separate packages and just have a
single "everything package". I think OASIS would be happier
if we did that anyway.
What package contains what components
doesn't really change what a user can use, what can be specialized from
what, or what can reference what. And assuming tools can use catalogs,
the actual filenames and locations don't matter very much either.
Or are we talking about something other
than packaging?
· About
the Public IDs and URIs that are used to reference the various files?
· About
the file and folder names and locations used to hold the files?
· About
what document type shells are made available in which package or in which
folders?
· About
how the written specification is organized?
-Jeff
> -----Original Message-----
> From: Rob Hanna [mailto:]
> Sent: Monday, August 24, 2009 12:10
PM
> To: Grosso, Paul; dita
> Subject: Re: [dita] problem with
packaging of glossaries [but not
> really]
>
> I think the point is that we are
not ready to separate the three
> archetypes from the base specification.
In the absence of any semantic
> alternatives, concept, task, and
reference should remain within the
> core of the standard for this release.
>
> New users need to reference the information
types in order to
> understand how topics are constructed
based upon the information they
> represent. Topic alone contains no
semantic markup at all. Even if new
> users reject concept, task, and reference
within their environment,
> they need to see how these fit in
order to develop their own relevant
> specializations. As Tim Grantham
said in an earlier post, there ought
> to be few instances where DITA is
considered where they could not be
> used.
>
> I believe that with further analysis
and discussion that we may be in a
> position to consider the separation
of tech pub info types from the
> base in DITA 1.3.
>
> Cheers,
> Rob Hanna
> ------Original Message------
> From: Grosso, Paul
> To: dita
> Subject: RE: [dita] problem with
packaging of glossaries [but not
> really]
> Sent: 24 Aug 2009 11:40 AM
>
>
> Just what do people think the discussion
is at this point?
>
> Is it still packaging? Because
if it is, I'm completely confused.
>
> As both Michael and Jeff have pointed
out, packaging is just how
> we ship the files. It is not
whether someone can use this or that
> file or doctype as a basis for specialization
or creation of their
> particular DITA application, yet
that still seems to be the core
> of most of the continued discussion.
>
> If we aren't still talking about
packaging, can we change the
> subject line (to whatever we're discussion,
which I don't really
> understand).
>
> If we are talking about packaging,
can someone explain how most
> of the discussion has anything to
do with packaging?
>
> paul
>
> > -----Original Message-----
> > From: Kristen James Eberlein
[mailto:]
> > Sent: Monday, 2009 August 24
10:34
> > Cc: dita
> > Subject: Re: [dita] problem
with packaging of glossaries
> >
> > Elliot, would you elaborate
on the "many uses of DITA" for which task,
> > concept, and reference are irrelevant?
I think it would help move
> this
> > discussion forward to have concrete
examples and use cases.
> >
> > Best,
> >
> > Kris
> >
> > ekimber wrote:
> > >
> > > Concept, task and reference
are not "universal". There are many
> uses
> of DITA
> > > for which they are completely
irrelevant.
> > >
> > > That particular breakdown
is specific to a particular technical
> > > communication practice
and philosophy and even that philosophy is
> not
> > > universal among technical
communicators.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list,
you must leave the OASIS TC that
> generates this mail. Follow
this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> Sent from my BlackBerry device on
the Rogers Wireless Network
