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

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: http://www.hyperwrite.com/Articles/showarticle.aspx?id=88
> 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="inst-demo.dita" rev="demo"/>
> <topicref href="inst-std.dita" rev="1.x"/>
> <topicref href="inst-upd.dita" rev="2.x"/>
> ...
> </map>
> ------------------------
> -seth park

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

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