[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. Cheers, Eliot 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 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]