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

[Michael Priestley <mpriestl@ca.ibm.com>]

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

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

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