OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] RE: Refinements to DITAVAL for Flagging?


Hmm, that sounds like a job for subjectScheme (the associating of values to
establish equivalence). Essentially you have two taxonomies that need to be
correlated. SubjectScheme can do that.

There's nothing that prevents the use of topicrefs today to point to ditaval
files, e.g.:

<topicref 
 processing-role="resource-only"
 href="ditaval/ditaval-01.ditaval"
 format="ditaval"
/>

I would expect processors that don't recognize "ditaval" as a format to
simply ignore this reference, or at least report it as an unrecognized
resource type. 

Of course, if that's a useful thing to do it would be good to codify it. But
you could experiment with it now, e.g., by hacking the Toolkit to do
something with the above and see how well it works in practice.

The implication of that type of tight map-to-ditaval binding is that the
publication reflects an invariant set of conditions (or an invariant subset
of the conditions reflected in the publication), which might make sense if
you have, for example, product-release-and-platform-specific root maps.

On the other hand, the implication of having it in the map is that either:

- Such references must themselves be unconditional (otherwise you'd have to
evaluate an initial set of conditions to determine which map-linked DITAVAL
you then apply to the rest of the content)

- Or the filtering processor has to first find all such references, taking
an initial filtering spec into account, evaluate them, and then apply normal
filtering processing to the entire map. This would necessarily involve
constructing a map tree taking into account only the initial filtering spec.
That map tree would be distinct from the key space construction map tree and
the rendition processing map tree.

Another potential complexity would be what to do with multiple references?
There would have to be precedence rules and such like, as we have for
keyref. That would also raise the issue of conditions that are scoped to
submaps. Maybe this would be a way to do it, maybe it would just make it
worse.

An alternative approach would be to provide a single ditaval reference
attribute on <map>, but that would still allow multiple references through
submaps, so I'm not sure it would help. If we're going to overload
<topicref> for all sorts of things we might as well be consistent about it.

The DITAVAL specification doesn't explicitly disallow multiple DITAVAL files
being used to configure a processor (nor should it) and I would certainly
like to specify multiples, for example to have one that handles filtering
and another that handles revision flagging, which are usually orthogonal
areas of concern. But when it's a processor that is getting the DITAVAL
files as a parameter it can define its own rules for ordering and
precedence.

Cheers,

E.


On 2/18/11 9:29 AM, "Park Seth-R01164" <R01164@freescale.com> wrote:

> Most of our (Freescale's) requirements demand that maps can link to "ditaval"
> (or whatever we end up with) files, suggesting that whatever approach we use
> will require "ditaval" to be part of the DITA architecture, with well-defined
> link behaviors.
> 
> So, I'm fully prepared to emerge with something that is very different from
> ditaval, perhaps something that provides a framework for establishing semantic
> equivalency for select-att *values*. If I pass a data set to CompanyX, we
> should be able to say, "your 'topsecret' is my 'internalOnly'."
> 
> 
> 
> -sp
> 
> 
> 
> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Friday, February 18, 2011 9:12 AM
> To: Park Seth-R01164; dita
> Subject: Re: [dita] RE: Refinements to DITAVAL for Flagging?
> 
> That would be good. I've only started really thinking about DITAVAL now since
> I've never needed it in my daily practice.
> 
> Of course, the other question is "should we?". DITAVAL is not manditory and
> there are tools that already provide their own filtering and flagging
> configuration mechanisms.
> 
> Cheers,
> 
> E.
> 
> 
> On 2/18/11 8:15 AM, "Park Seth-R01164" <R01164@freescale.com> wrote:
> 
>> Hi Eliot,
>> 
>> I have designs for ditaval management and schema changes on the 1.3
>> requirements wiki. For instance, I want a "description" attribute so
>> users and leave usage notes for other users regarding when to show/hide.
>> 
>> I'd like to go over them with you and anybody else that wants to
>> revamp ditaval for 1.3.
>> 
>> 
>> -seth park
>> 
>> 
>> -----Original Message-----
>> From: Eliot Kimber [mailto:ekimber@reallysi.com]
>> Sent: Friday, February 18, 2011 7:03 AM
>> To: dita
>> Subject: [dita] Refinements to DITAVAL for Flagging?
>> 
>> I'm learning about DITAVAL for the first time in any depth and I'm
>> seeing a couple of areas where it could be usefully extended, I think.
>> 
>> Have we discussed or has anyone else given thought to extending
>> DITAVAL? I didn't see anything in the current 1.3 issue list.
>> 
>> So far I've thought of the following two things:
>> 
>> 1. Better support for effectivity statements by allowing for example a
>> keyref to the DITA content to use for the effectivity statement (so
>> that the statement can have arbitrary DITA markup).
>> 
>> 2. Allow either arbitrary values for @style on <prop> or <revprop> or
>> allow all the values allowed for text-decoration in CSS 3. In
>> particular, the current spec does not allow strike through as a value.
>> 
>> 
>> Cheers,
>> 
>> E.
>> 
>> --
>> Eliot Kimber
>> Senior Solutions Architect
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368
>> www.reallysi.com
>> www.rsuitecms.com
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> 
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

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