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

["Nitchie, Chris" <cnitchie@ptc.com>]

This would also be useful for the @print replacement we were discussing last meeting, e.g.

print
  pdf
  paper
nonprint
  html
    frameset
  help
    eclipse
    ms-help
  wiki
    mediawiki
    moinmoin
    tiki
  ebook
    epub
      bn-nook
    mobi
      az-kindle

etc.

Chris

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Michael Priestley
Sent: Monday, December 19, 2011 11:52 AM
To: Eliot Kimber
Cc: dita; Park Seth-R01164
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: 

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 

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
>  
> 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


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