[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] implications of @print and @rev
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]