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?


Hi,
>> Have we discussed or has anyone else given thought to extending
>> DITAVAL? I didn't see anything in the current 1.3 issue list.

The DITA machine industry SC has discussed the conditional processing support in DITA. There is a proposal now for DITA 1.3 (proposal 13017). The 13017 proposal is saying:

“In many cases it is needed to use other values than "Product", "Platform", "Audience" or "otherprops" as values for filtering of elements in a topic. For example "Component", "Market", "Manual_type", "Technology_standard", "Customer", "Language" etc. To include all possible values would make the list of attributes very long on each element and even in that case some values might be missing for some application. Instead of trying to cover all possible needed values a more generic approach should be introduced.”

I need to update the 13017 proposal due to subject scheme, since clearly the subject scheme will give additional possibilities. The idea of using the subject scheme for filtering purposes was discussed in the original subject scheme proposal (see the draft-comments).

Please give me feedback on the below proposal. 

Consider a subject scheme “SubjectScheme1.xml” as:

<subjectScheme>
  <subjectdef keys="products">
    <subjectdef keys="productA"/>
    <subjectdef keys=" productB"/>
    <subjectdef keys=" productC"/>
  </subjectdef>
</subjectScheme>

And a classifying map as:

<map id=”ProductAB” schemeref=”SubjectScheme1.xml”>
  <title>Products A, B</title>
  <topicref href="productsGeneric.dita">
    <topicsubject>
      <subjectref keyref="productA"/>
      <subjectref keyref="productB"/>
    </topicsubject>
  </topicref>
  <topicref href="productsA.dita">
    <topicsubject>
      <subjectref keyref="productA"/>
    </topicsubject>
  </topicref>
  <topicref href="productsB.dita">
    <topicsubject>
      <subjectref keyref="productB"/>
    </topicsubject>
  </topicref>
</map>

In topics (for example “productsGeneric.dita” below) we need in DITA 1.3 to introduce a “subjectref” attribute:

<concept id="xxx">
  <title>Products…</title>
  <body>
     <p subjectref=”productA”>Product A is…</p>
     <p subjectref=”productB”>Product B is…</p>
  </body>
</concept>

In the subjectScheme1 we must declare the subjectref attribute

<subjectScheme>
  <subjectdef keys="products">
    <subjectdef keys="productA"/>
    <subjectdef keys=" productB"/>
    <subjectdef keys=" productC"/>
  </subjectdef>
  <enumerationdef>
    <attributedef name="subjectref"/>
    <subjectdef keyref="products"/>
  </enumerationdef>
</subjectScheme>

The subjectref is then a generic filtering attribute for adopters who do not want to use the products, platform, audience and otherprops filtering attributes, since they are clearly software oriented and do not apply in some applications. For example in machine industry you would need filtering attributes like “feature”, “component”, “sub-assembly”, “material-number” (similar to the metadata that is given in the prolog) etc and to extend the filtering attributes is not a path we want to go?

The DITA val (myditaval1.ditaval below) is then extended to reference subjects in the subject scheme to take action upon (subjectref element and attributes) according to:

<val>
  <prop element="subjectref" keyref="productA" action="exclude">
  <prop att="subjectref" keyref="productA" action="exclude">
  </prop>
</val>

Processing the above DITA val file should leave the map id=”ProductAB” as:

<map id=”ProductAB” schemeref=”SubjectScheme1.xml”>
  <title>Products A, B</title>
  <topicref href="productsGeneric.dita">
    <topicsubject>
      <subjectref keyref="productA"/>
      <subjectref keyref="productB"/>
    </topicsubject>
  </topicref>
  <topicref href="productsB.dita">
    <topicsubject>
      <subjectref keyref="productB"/>
    </topicsubject>
  </topicref>
</map>

And topic “productsGeneric.dita” as:

<concept id="xxx">
  <title>Products…</title>
  <body>
     <p subjectref=”productB”>Product B is…</p>
  </body>
</concept>

But we need a mechanism to declare which DITA val file to use for a map?

<map id=”ProductAB” schemeref=”SubjectScheme1.xml” ditaval=”myditaval1.ditaval”>

And the ditaval to reference the subjectscheme?

<val schemeref=”SubjectScheme1.xml”>
  <prop element="subjectref" keyref="productA" action="exclude">
  <prop att="subjectref" keyref="productA" action="exclude">
  </prop>
</val>

Also, an extended support in DITA 1.3 should take Boolean operators into account to build conditional statements. And also the DITA val processing, when action is set to “include”, should automatically exclude everything else. 

Best regards,
Jonatan
________________________________________
From: Eliot Kimber [ekimber@reallysi.com]
Sent: Friday, February 18, 2011 4:48 PM
To: Park Seth-R01164; dita
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


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


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