OASIS Darwin Information Typing Architecture (DITA) TC

Referring another comment to the TC for discussion: Topic = DITAVAL elements DITAweb URL: http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL elements Prose in question: Notes on ditaval messages Conditional processing code should provide a report of any attribute values encountered in content that do not have an explicit action associated with them. Comments: Eliot Kimber: I think this needs to clarify that specifying an attribute with no value constitutes an explicit action. Currently the OT will report attribute values that are defaulted to exclude via prop elements. It should not. Robert Anderson: I'm finding this whole sentence somewhat questionable. I'm not sure the spec should be forcing applications to do this. Referring to TC for thoughts. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype)

I agree with Robert: I don't think the requirement has any particular value. I can see the utility, as a processor-supplied option, of reporting values that don't have explicit actions, if you're concerned about overlooked conditions, but I would see that as a debugging utility you'd turn on occasionally, not something processors should be expected to do all the time. Nothing in the spec precludes processors from reporting any information they want during processing. But there's no need to require it in this case. Personally, I find the messages the OT puts out both annoying (because I know that I intentionally didn't set actions for those values by taking advantage of the ability to set the default action) and, even though they are flagged as informational, I still initially read them as warnings or errors and I'm sure many other users do too. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 11/1/14, 9:06 AM, "Kristen James Eberlein" <kris@eberleinconsulting.com> wrote: > > > > > > > Referring another comment to the TC for discussion: > > Topic = DITAVAL elements > DITAweb URL: > http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL > elements > > Prose in question: > > Notes on ditaval messages > Conditional processing code should provide a report of any attribute > values encountered in content that do not have an explicit action > associated with them. > > Comments: > > >* Eliot Kimber: "I think this needs to clarify that specifying > an attribute with no value constitutes an explicit action. > Currently the OT will report attribute values that are defaulted > to exclude via prop elements. It should not." > >* Robert Anderson: "I'm finding this whole sentence somewhat > questionable. I'm not sure the spec should be forcing > applications to do this. Referring to TC for thoughts." > > > > -- > Best, > Kris > > Kristen James Eberlein > Chair, OASIS DITA Technical Committee > Principal consultant, Eberlein Consulting > www.eberleinconsulting.com < http://www.eberleinconsulting.com > > +1 919 682-2290; kriseberlein (skype) > > > > > >--------------------------------------------------------------------- >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 > >

I'm conflicted. There's an implicit 'include' for things that don¹t have an explicit 'exclude' and I think that intuitively makes sense. I don't have any objection to a particular processor calling out when that situation happens, but suggesting that *all* processors should act that way strikes me as very unnecessary. Chris Chris Nitchie (734) 330-2978 chris.nitchie@oberontech.com www.oberontech.com < http://www.oberontech.com/ > Follow us: < https://www.facebook.com/oberontech > < https://twitter.com/oberontech > < http://www.linkedin.com/company/oberon-technologies > On 11/1/14, 10:18 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: >I agree with Robert: I don't think the requirement has any particular >value. > >I can see the utility, as a processor-supplied option, of reporting values >that don't have explicit actions, if you're concerned about overlooked >conditions, but I would see that as a debugging utility you'd turn on >occasionally, not something processors should be expected to do all the >time. Nothing in the spec precludes processors from reporting any >information they want during processing. But there's no need to require it >in this case. > >Personally, I find the messages the OT puts out both annoying (because I >know that I intentionally didn't set actions for those values by taking >advantage of the ability to set the default action) and, even though they >are flagged as informational, I still initially read them as warnings or >errors and I'm sure many other users do too. > >Cheers, > >E. >‹‹‹‹‹ >Eliot Kimber, Owner >Contrext, LLC > http://contrext.com > > > > >On 11/1/14, 9:06 AM, "Kristen James Eberlein" ><kris@eberleinconsulting.com> wrote: > >> >> >> >> >> >> >> Referring another comment to the TC for discussion: >> >> Topic = DITAVAL elements >> DITAweb URL: >> http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL >> elements >> >> Prose in question: >> >> Notes on ditaval messages >> Conditional processing code should provide a report of any attribute >> values encountered in content that do not have an explicit action >> associated with them. >> >> Comments: >> >> >>* Eliot Kimber: "I think this needs to clarify that specifying >> an attribute with no value constitutes an explicit action. >> Currently the OT will report attribute values that are defaulted >> to exclude via prop elements. It should not." >> >>* Robert Anderson: "I'm finding this whole sentence somewhat >> questionable. I'm not sure the spec should be forcing >> applications to do this. Referring to TC for thoughts." >> >> >> >> -- >> Best, >> Kris >> >> Kristen James Eberlein >> Chair, OASIS DITA Technical Committee >> Principal consultant, Eberlein Consulting >> www.eberleinconsulting.com < http://www.eberleinconsulting.com > >> +1 919 682-2290; kriseberlein (skype) >> >> >> >> >> >>--------------------------------------------------------------------- >>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 >

The impact of the uncorrected condition seems to be simply that the rule never finds a matching trigger condition. The IMPLIED default value certainly allows such coding, and it's still a valid rule that has an expected result--it won't trigger. The editor or the CMS could QA check this condition just as well as a processor. I'd leave the note heading, but a possible rewrite of the content might be: ------------- Note that any prop with an empty or missing or undefined value of the action attribute may fail to trigger any expected conditional processing for that prop. In fact, misnaming an @att or @action value is a valid way of commenting out the contribution of a prop at an author's prerogative. A preferred order of bringing informational attention to this case in a workflow might be: 1) in the editor's file save exit code; 2) in the CMS check-in code; 3) in the processor's ditaval loading code (least efficient). ---------------- I initially used rule instead of prop because the issue is more clearly understood in how rules engines work, but the spec does not use that term,  so prop it is for now. Don R. Day Co-Founder, ContelligenceGroup.com Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday    Twitter: @donrday About.me: Don R. Day    Skype: don.r.day Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? --T.S. Eliot

As a DITA (and DITA-OT) user, this processor feedback is extremely important to me.
 
In my world, we build maps of topics and maps assembled by different teams using different workflows. Keeping my ditaval file up-to-date with the prop usage is
crucial to avoid creating an incorrect rendition (due to filtering problems). (For the record, I know how subjectScheme could help me proactively manage this issue, but we’ve not been able to implement it in our environment.)
 
If I process my top map with a ditaval file and someone else has included an unknown prop (or misspelled the prop value), then I need to know about it.

 
As a DITA user, I will insist that any DITA processor provide this feedback, so having something in the spec that calls attention to this usecase seems like a
good thing.
 
Perhaps we can just say “may” instead of “should” as a way of implying the need to tool developers?
 
-seth
 
 
 
 
 


From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
On Behalf Of Kristen James Eberlein
Sent: Saturday, November 01, 2014 9:07 AM
To: DITA TC
Subject: [dita] Review #2 comments: DITAVAL elements


 
Referring another comment to the TC for discussion:

Topic = DITAVAL elements
DITAweb URL:
http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL elements

Prose in question:

Notes on ditaval messages
Conditional processing code should provide a report of any attribute values encountered in content that do not have an explicit action associated with them.

Comments:


Eliot Kimber: "I think this needs to clarify that specifying an attribute with no value constitutes an explicit action. Currently the OT will report attribute values that are defaulted to exclude via prop elements. It should not."
Robert Anderson: "I'm finding this whole sentence somewhat questionable. I'm not sure the spec should be forcing applications to do this. Referring to TC for thoughts."

--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

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

At a minimum the change should be from SHOULD to MAY as Seth recommends. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 11/3/14, 11:07 AM, "seth.park@freescale.com" <seth.park@freescale.com> wrote: >As a DITA (and DITA-OT) user, this processor feedback is extremely >important to me. > >In my world, we build maps of topics and maps assembled by different >teams using different workflows. Keeping my ditaval file up-to-date with >the prop usage is > crucial to avoid creating an incorrect rendition (due to filtering >problems). (For the record, I know how subjectScheme could help me >proactively manage this issue, but we’ve not been able to implement it in >our environment.) > >If I process my top map with a ditaval file and someone else has included >an unknown prop (or misspelled the prop value), then I need to know about >it. > > >As a DITA user, I will insist that any DITA processor provide this >feedback, so having something in the spec that calls attention to this >usecase seems like a > good thing. > >Perhaps we can just say “may” instead of “should” as a way of implying >the need to tool developers? > >-seth > > > > > >From: dita@lists.oasis-open.org [ mailto:dita@lists.oasis-open.org ] >On Behalf Of Kristen James Eberlein >Sent: Saturday, November 01, 2014 9:07 AM >To: DITA TC >Subject: [dita] Review #2 comments: DITAVAL elements > > > >Referring another comment to the TC for discussion: > >Topic = DITAVAL elements >DITAweb URL: > http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL >< http://ditaweb.com/oasis-dita/#/00074601-DA$00074098-DB$DITAVAL > elements > >Prose in question: > >Notes on ditaval messages >Conditional processing code should provide a report of any attribute >values encountered in content that do not have an explicit action >associated with them. > >Comments: > >* >Eliot Kimber: "I think this needs to clarify that specifying an attribute >with no value constitutes an explicit action. Currently the OT will >report attribute values that are defaulted to exclude via prop elements. >It should not." >* >Robert Anderson: "I'm finding this whole sentence somewhat questionable. >I'm not sure the spec should be forcing applications to do this. >Referring to TC for thoughts." > >-- >Best, >Kris > >Kristen James Eberlein >Chair, OASIS DITA Technical Committee >Principal consultant, Eberlein Consulting >www.eberleinconsulting.com < http://www.eberleinconsulting.com > >+1 919 682-2290; kriseberlein (skype) > >--------------------------------------------------------------------- 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 >< https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >