Re: [dita] implications of @print and @rev

[Eliot Kimber <ekimber@reallysi.com>]

Being able to group releases logically, e.g., 2.x -> 2.1, 2.2, 2.3, etc.
would definitely take the sting out of having to enumerate every release.

I think the taxonomy idea is useful generally and definitely warrants more
thought.

Cheers,

E.



On 12/19/11 11:08 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> 
> Just had another thought - some of the logic could even be moved into the
> taxonomy. 
> 
> For example, if the version siblings are declared as a sequence
> (collection-type=sequence), could automatically assume that any filter on a
> particular node would also apply to its previous siblings.
> 
> Would that be safe as a general rule? Or would there still be cases where you
> want just the particular node?
> 
> If so, it might still be as simple as having two kinds of filter:
> 
> - filter exactly this value
> - filter this value and related
> 
> That syntax would apply to any kind of relationship you had in the taxo,
> including parent/child, next/prev...
> 
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
> 
> 
> From: Michael Priestley/Toronto/IBM@IBMCA
> To: Eliot Kimber <ekimber@reallysi.com>
> Cc: dita <dita@lists.oasis-open.org>, Park Seth-R01164 <R01164@freescale.com>
> Date: 12/19/2011 11:58 AM
> Subject: Re: [dita] implications of @print and @rev
> Sent by: <dita@lists.oasis-open.org>
> 
> 
> 
> 
> 
> 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:
> 
> product1 
>         prod1ver1
>         prod1ver2
>         prod1ver3
> 
> 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
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
> 
> 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.
> 
> 
> 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
>> <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