[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Potential Issue: When Does Applicability Apply to Key Space Determination?
Eliot asked: > So I guess we really have two questions: > > 1. Does anyone disagree with the assertion that
"filter first" > is/should be the working principle of the DITA 1.2
standard? I agree with this, but
feel that because this is coming so late in the DITA 1.2 cycle and because the
DITA 1.0, 1.1, and up until now DITA 1.2 specs have been silent about order of
processing issues, that if we are going to include this in DITA 1.2 that it
should be a SHOULD rather than a MUST. > 2. If everyone agrees that "filter first"
is the principle to apply to > processing generally, does anyone disagree with the
conclusion that key > spaces must therefore reflect the effect of
filtering? I agree with this too
and make the same comment about SHOULD rather than MUST in DITA 1.2. -Jeff > -----Original Message----- > From: ekimber [mailto:ekimber@reallysi.com] > Sent: Monday, November 02, 2009 3:58 PM > To: dita > Cc: Robert D Anderson > Subject: Re: [dita] Potential Issue: When Does
Applicability Apply to > Key Space Determination? > > I think that reasoning makes sense in general and it
also makes sense > for > the Toolkit that the natural implementation decision
would be to put > any new > processing, including keyref, after filtering. > > That seems to argue the general principle that
filtering is first. I > don't > know that that principle is formally stated or
clearly implied anywhere > in > the current spec. > > So I guess we really have two questions: > > 1. Does anyone disagree with the assertion that
"filter first" > is/should be > the working principle of the DITA 1.2 standard? > > 2. If everyone agrees that "filter first"
is the principle to apply to > processing generally, does anyone disagree with the
conclusion that key > spaces must therefore reflect the effect of
filtering? > > If the answer is "no" (no disagreement),
then the action would be to > update > the language in "Indirect content inclusion:
keys and conkeyref" under > the > "Linking and addressing" topic to include
an explicit statement that > filtering is applied before determining the key
space and that the > effective > key space may include multiple definitions of the
same key with > different > applicabilities. > > To recap, the implementation implication for
"filter first" on systems > that > need to be able to calculate key spaces that reflect
all possible sets > of > conditions used in a given information set is: > > 1. Either take a condition set (e.g., DIVAVAL
document) as a parameter > to > the keyspace construction or > > 2. Return a keyspace that reflects not just unique
keys but unique > key/condition set pairs, meaning that there may be
multiple instances > of the > same key reflecting different, unique sets of
conditions. > > Note that by "keyspace construction" is
implicitly meant also > "key-to-resource binding lookup" since you
can't resolve a key to a > resource > until you have first constructed the keyspace. The
key mechanism > already > requires a root map as a parameter to the keyspace
construction process. > > And again, this is primarily a practical issue for
authoring and > retrieval, > not rendition processing. > > In general I think of authoring as involving both an
authoring tool > (editor) > and a "link management service" that
supports the editor by optimizing > knowledge of links and addresses, in particular,
what the set of > available > targets are (think I can address and therefore link
to) and, for a > given > thing that *could* be addressed, that things do in
fact address it > (where > used). > > I call this a "link management service",
rather than content management, > because it could be implemented as a standalone
service applied to data > that > is otherwise not managed (e.g., topics on a file
system or in a code > control > system or whatever) or it could be built into the
editor (e.g., > OxygenXML's > built-in support for keys). However, one would
normally expect link > management services to be provided by more expansive
content management > systems that also provide versioning, access
control, searching, and so > on. > > Cheers, > > Eliot > > > On 11/2/09 3:40 PM, "Robert D Anderson"
<robander@us.ibm.com> wrote: > > > Hi Eliot, > > > >> I see that the current 1.5 Toolkit does
filtering before doing any > other > >> processing. Is that a considered decision
or just the way the > > implementation > >> fell? > > > > It was a considered decisions with regards to
all other aspects of > DITA > > processing, though we did not re-examine that
decision in light of > keyref. > > The reasoning has been discussed on this list
and others, but it is > > primarily based on experiences that the IBM
team had in the early > > (pre-standard) days of DITA. The two primary
reasons to do it this > way are > > 1) improve processing speed by dropping content
you won't use as soon > as > > possible, and more importantly 2) do not try
and retrieve content > that will > > never be needed. For example, if I have this: > > <p
conref="productA-info.dita#topic/p" product="a"/> > > > > If I want to filter out all product A
information, then I drop this > early > > on in my processing. The build does not
retrieve productA-info.dita, > which > > may not even be available. The conref
processing is also skipped, > which > > saves a bit of time. > > > > The bigger issue for many of my own users is
that when they package > up > > information to send off to a translator, they
do not need to ship > > productA-info.dita, because the conref is
filtered out and never > resolved. > > So, no money is wasted translating the file
that will not be used. > This > > issue, rather than the slight processing speed
improvement, was the > main > > one that resulted in the current processing
order. > > > > As I said, when keyref came around, we didn't
step back to re-address > that > > issue, but it does make me wonder - if you have
a key definition that > wins > > with no ditaval, but is filtered out when you
try to render the > content, > > how could that key still be valid in your
rendered files? I guess > that's > > partly what you're asking. At this point I
would expect the results > you're > > getting from the OT today, but I'm obviously
thinking about this from > an OT > > style publishing perspective rather than from
an editor or CMS > perspective. > > > > Robert D Anderson > > IBM Authoring Tools Development > > Chief Architect, DITA Open Toolkit > > > > ekimber <ekimber@reallysi.com> wrote on
11/02/2009 02:25:28 PM: > > > >> ekimber <ekimber@reallysi.com> > >> 11/02/2009 02:25 PM > >> > >> To > >> > >> dita <dita@lists.oasis-open.org> > >> > >> cc > >> > >> Subject > >> > >> [dita] Potential Issue: When Does
Applicability Apply to Key Space > >> Determination? > >> > >> Something that came up in the context of a
discussion I was having > on how > >> one would normally process DITA content in
the context of keys led > to the > >> question of when conditional processing is
applied to key > definitions. > >> > >> In particular, is filtering applied before
or after the key space is > >> determined for a given map? > >> > >> If filtering is applied before the keyspace
is determined, it means > that > > you > >> cannot determine a key space given just a
map: you must also specify > a > >> DITAVAL file (or its equivalent). It also
means that the same map > tree > > may > >> produce different key spaces for different
DITAVAL files. Or rather, > it > >> means that a key space is not simply a
unique set of keys, but a > unique > > set > >> of key/property pairs (where the same key
may occur more than once > as > > long > >> as each instance has distinct
applicability). > >> > >> If filtering is applied after the keyspace
is determined, then you > cannot > >> have key definitions that use conditional
processing. > >> > >> From an implementation standpoint, applying
filtering *before* > keyspace > >> determination significantly complicates key
space calculation for > systems > >> that just deal with keys (e.g., authoring
systems) and are not doing > >> sequential processing of DITA content. > >> > >> If filtering is done before keyspace
determination it means that all > >> processors that work with key spaces must
take as a parameter to any > key > >> lookup both the root map *and* the set of
applicable conditions or > else > > they > >> have to include in any set of available
keys all key definitions > that > > have > >> unique applicability, that is, for a given
key, the first of each > > definition > >> with a unique set of @props values, that
is, the set of definitions > that > >> *could* be effective. This would definitely
complicate key space > >> calculation, but it could be done if the
requirement is understood > up > > front > >> and systems are designed to accommodate it. > >> > >> If filtering is done after keyspace
determination, it means that > > conditions > >> don't affect key definition (that is, a
key-defining topicref that > would > > be > >> filtered out is not filtered out for the
purpose of defining keys). > >> > >> I see that the current 1.5 Toolkit does
filtering before doing any > other > >> processing. Is that a considered decision
or just the way the > > implementation > >> fell? > >> > >> From a CMS and authoring tool
implementation standpoint doing > filtering > >> *after* key space determination would be
easiest to implement but I > > suspect > >> that that is too limiting as it denies use
of filtering for key > > definition > >> management. > >> > >> Do we already have a definitive answer to
this question? If not, is > there > >> consensus about what the right answer is? > >> > >> Thanks, > >> > >> Eliot > >> > >> ---- > >> Eliot Kimber | Senior Solutions Architect |
Really Strategies, Inc. > >> email: ekimber@reallysi.com
<mailto:ekimber@reallysi.com> > >> office: 610.631.6770 | cell: 512.554.9368 > >> 2570 Boulevard of the Generals | Suite 213
| Audubon, PA 19403 > >> www.reallysi.com
<http://www.reallysi.com> | > http://blog.reallysi.com > >> <http://blog.reallysi.com> |
www.rsuitecms.com > <http://www.rsuitecms.com> > > > >> > >> > >>
-------------------------------------------------------------------- > - > >> 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 > >> > > > > ---- > Eliot Kimber | Senior Solutions Architect | Really
Strategies, Inc. > email: ekimber@reallysi.com
<mailto:ekimber@reallysi.com> > office: 610.631.6770 | cell: 512.554.9368 > 2570 Boulevard of the Generals | Suite 213 |
Audubon, PA 19403 > www.reallysi.com <http://www.reallysi.com> |
http://blog.reallysi.com > <http://blog.reallysi.com> | www.rsuitecms.com > <http://www.rsuitecms.com> > > > --------------------------------------------------------------------- > 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]