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] Review #2 comments: DITAVAL elements


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




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