[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] problem with packaging of glossaries [but not really]
|
This topic has elicited quite a bit of
concern from the BusDocs committee based on the perceived understanding of
packaging. Your concept of packaging being a zip file appears to be different
than our understanding. If it is a simple as a .zip file and each package can
have unique and similar components (e.g., glossary, and other info types could
simultaneously exist in multiple packages (e.g., reuse)) then there wouldn’t
be any concern on our part, but rather it appears as though info types can only
exist in one package or another. This may be trite, but why can’t we
treat the spec as having multiple audiences and create a spec and associated
packages that reuses and presents the content as appropriate to that audience. I
realize that this is occurring with TD and their own spec, but it appears as
though the actual into types are moving as well. Offloading everything now
seems to be an extreme move. We realize that there are a number of key issues
that need to be addressed in 1.2 and don’t want to detract from these
issues, but this is one of ours and it impacts not only our work, but
potentially other subcommittee work. I have pulled together some of the emails
to identify why this appears to be more than a simple package question (e.g.,
zip file), rather it affects the standard and that seems to be a pretty big
decision to make. Maybe this should be a special meeting so we can address it
outside of the email. Paul Gross, initial message, Aug. 20.
Glossentry exists only in the TD package not in the base. Item 2 suggests this
is also true of task, concept and reference. “The
problem: <glossentry> is specialized from <concept>. <task>,
<concept>, and <reference> are in the TechDocs package. This forces
<glossentry> etc. to be restricted to the TD package. But
non-TechDocs folks need glossaries, and support for them should be in the base. Two
solutions:
JoAnn
Hackos, Aug. 20. Also implies that these info types are part of the TD package
only. “I am in favor of Bruce’s
second recommendation. What is the problem with stating that concept, task, and
reference are key specializations in the DITA standard? Why should they be
relegated to technical communication only? I just don’t see the point of
that. Even if there is a All DITA package,
we’re not including information about task, concept, and reference
information types in the base architectural specification, but only in the arch
spec for technical communication. I’ve never been in favor of this
split and would strongly prefer that we include task, concept, reference, and
glossary in the base architectural specification. That would leave us with the
machine industry specialization, which is, of course, extremely relevant for
many outside the machine industry, and the various domains (software, ui,
programming, machine industry, safety hazard). Also bookmap. Why is bookmap
considered relevant only for technical communication. It’s probably less
relevant there and more relevant for DocBook aficionados.” And Michael Priestly’s response Aug.
21, which also implies that it is in one package and not another. “The point of a separate base package is to
provide the bare minimum of DITA support - just topic, map, basic utility
domain. From: Ogden, Jeff
[mailto:jogden@ptc.com] 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: >
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 >
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, >
>
------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:keberlein@pobox.com] >
> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]