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: Re: [dita] implications of @print and @rev

Hi Eliot,

One possibility is to expand filtering's awareness of relationships in a taxonomy map.

Then, if you have a taxonomy that declares keys like this:


You've handled product and version in a single hierarchy, and the relationship between them using the hierarchy.

Filtering out "prod1" could also automatically filter out anything tagged with its children; and filtering out "less than prod1ver3" should filter out prod1ver1, and prod1ver2

Given use of a taxonomy to declare the relationships, it doesn't seem like the problem would grow exponentially more complex - just one or two more filter actions in the ditaval.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect

From: Eliot Kimber <ekimber@reallysi.com>
To: Park Seth-R01164 <R01164@freescale.com>, dita <dita@lists.oasis-open.org>
Date: 12/19/2011 11:28 AM
Subject: Re: [dita] implications of @print and @rev
Sent by: <dita@lists.oasis-open.org>

The 1.2 (and earlier) specs specifically say that @rev should not be used
for filtering. As I understand it, @rev is intended to reflect
revisions-in-time of *the document*, not revisions of the thing documented.

That suggests that a separate @props specialization is required for
filtering on product release, if you want to do that.

Of course, one challenge there is doing something like "filter out
everything that applies to releases *after* release 1.2", which can't be
done directly with the current binary-choice filtering mechanism--that is,
each release has to be enumerated both in the @props attribute and in the
filtering spec. You would need an _expression_ language that let you perform
greater that/less that/equals comparisons on values. We could certainly
design that but a general _expression_ approach for filtering is something
we've so far avoided (and I point to S1000D as a cautionary tale if I
understand the purported horrorshow that is S1000D conditional processing).

For that reason, version-in-time filtering is, I think, fundamentally a
configuration management issue for which DITA filtering is not really
intended--it's a content management and link management issue, one that
should be solved at the content management layer.

I could see designing a very-focused mechanism specifically for doing
numerical comparison of numeric release numbers--could even borrow operators
for XPath 2 to avoid issues with < and >--but I would not want to open the
door to a general filtering _expression_ language. It would require defining
both the lexical format for release numbers and the _expression_ language for
operating on them.



On 12/19/11 10:03 AM, "Park Seth-R01164" <R01164@freescale.com> wrote:

> On the 13 Dec 2011 call, we discussed the implications of @print on keyspace
> construction. In research regarding use cases for @rev, I discovered evidence
> that suggests that @rev when used on a topicref is effectively a method of
> filtering, similar to the usage of @print.
> I am not personally yet familiar with this processing mechanism, but I bring
> it up to ensure it¹s been considered.
> ---------------------
> Source:
> Map metadata is used at the top of the metadata food chain to apply filtering
> characteristics to whole topics or topic groups within maps. We could, for
> example, construct a single map that allows us to produce a user guide for any
> of several product releases by adding rev metadata attributes to the topic
> references, like this:
> <map title="User Guide" id="userguide">
> <topicref href="" rev="demo"/>
> <topicref href="" rev="1.x"/>
> <topicref href="" rev="2.x"/>
> ...
> </map>
> ------------------------
> -seth park

Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368

To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org

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