OASIS Darwin Information Typing Architecture (DITA) TC

While doing an exhaustive review of our new keyscope material with Kris, I realized that the keyscope attribute is available on <relcolspec> (it's part of the general group of topicref attributes that gets reused on relcolspec). This came up because the current definition of what goes in a key scope covers child elements in the map, along with stuff referenced by those elements. Logically, I think a key scope on a relcolspec would have to cover all of the reltable cells and topicrefs from that single column of the reltable - but this isn't called out anywhere. That said ... I have to wonder if we'd be better off removing @keyscope from this element? Doing so would somewhat complicate the grammar files (not sure how much). But, it would also simplify the definition of key scopes (because we would not have to add language for this case). It would also mean implementations do not have to worry about this case, which I'm thinking is extremely unlikely. If I try, I can come up with cases where somebody could conceivably try this - but I can't come up with a case where the pain of managing that sort of markup would be worth it. So, I think the options are - update the spec to explicitly cover this edge case (@keyscope on relcolspec means XYZ), or my preferred option, remove @keyscope from relcolspec. Thoughts? Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit ( http://www.dita-ot.org/ )

I certainly never intended to have @keyscope on relcolspec. This is just a side-effect of the reuse of the parameter entity defining those attributes. I
strongly  support its removal from relcolspec.


Chris







Chris Nitchie
(734) 330-2978
chris.nitchie@oberontech.com
www.oberontech.com







Follow us:











 











  See us at the  DITA
North America  2015 conference, April 20-22 in Chicago, Il.  Learn how our expert services and innovative solutions can meet your content and publishing needs.










From: Robert D Anderson
Date: Thursday, April 16, 2015 at 4:22 PM
To: DITA TC
Subject: [dita] @keyscope on <relcolspec>





While doing an exhaustive review of our new keyscope material with Kris, I realized that the keyscope attribute is available on <relcolspec> (it's part of the general group of topicref attributes that gets reused on relcolspec).

This came up because the current definition of what goes in a key scope covers child elements in the map, along with stuff referenced by those elements. Logically, I think a key scope on a relcolspec would have to cover all of the reltable cells and topicrefs
from that single column of the reltable - but this isn't called out anywhere.

That said ... I have to wonder if we'd be better off removing @keyscope from this element? Doing so would somewhat complicate the grammar files (not sure how much). But, it would also simplify the definition of key scopes (because we would not have to add language
for this case). It would also mean implementations do not have to worry about this case, which I'm thinking is extremely unlikely. If I try, I can come up with cases where somebody could conceivably try this - but I can't come up with a case where the pain
of managing that sort of markup would be worth it.

So, I think the options are - update the spec to explicitly cover this edge case (@keyscope on relcolspec means XYZ), or my preferred option, remove @keyscope from relcolspec.

Thoughts?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit ( http://www.dita-ot.org/ )

I agree: the potential side effects are too great. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 4/16/15, 3:27 PM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote: >I certainly never intended to have @keyscope on relcolspec. This is just >a side-effect of the reuse of the parameter entity defining those >attributes. I >strongly support its removal from relcolspec. > > >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 > > > See us at the DITA > North America < http://www.cm-strategies.com/2015/index.htm > 2015 >conference, April 20-22 in Chicago, Il. Learn how our expert services >and innovative solutions can meet your content and publishing needs. > > > > > > > > >From: Robert D Anderson >Date: Thursday, April 16, 2015 at 4:22 PM >To: DITA TC >Subject: [dita] @keyscope on <relcolspec> > > > >While doing an exhaustive review of our new keyscope material with Kris, >I realized that the keyscope attribute is available on <relcolspec> (it's >part of the general group of topicref attributes that gets reused on >relcolspec). > >This came up because the current definition of what goes in a key scope >covers child elements in the map, along with stuff referenced by those >elements. Logically, I think a key scope on a relcolspec would have to >cover all of the reltable cells and topicrefs > from that single column of the reltable - but this isn't called out >anywhere. > >That said ... I have to wonder if we'd be better off removing @keyscope >from this element? Doing so would somewhat complicate the grammar files >(not sure how much). But, it would also simplify the definition of key >scopes (because we would not have to add language > for this case). It would also mean implementations do not have to worry >about this case, which I'm thinking is extremely unlikely. If I try, I >can come up with cases where somebody could conceivably try this - but I >can't come up with a case where the pain > of managing that sort of markup would be worth it. > >So, I think the options are - update the spec to explicitly cover this >edge case (@keyscope on relcolspec means XYZ), or my preferred option, >remove @keyscope from relcolspec. > >Thoughts? > >Robert D Anderson >IBM Authoring Tools Development >Chief Architect, DITA Open Toolkit ( http://www.dita-ot.org/ ) > > >

Please -- Let's remove it. It's worth doing some gymnastics with the grammar files (although I suspect we'll just need a new parameter entity or the RNG equivalent). Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 4/16/2015 4:22 PM, Robert D Anderson wrote: While doing an exhaustive review of our new keyscope material with Kris, I realized that the keyscope attribute is available on <relcolspec> (it's part of the general group of topicref attributes that gets reused on relcolspec). This came up because the current definition of what goes in a key scope covers child elements in the map, along with stuff referenced by those elements. Logically, I think a key scope on a relcolspec would have to cover all of the reltable cells and topicrefs from that single column of the reltable - but this isn't called out anywhere. That said ... I have to wonder if we'd be better off removing @keyscope from this element? Doing so would somewhat complicate the grammar files (not sure how much). But, it would also simplify the definition of key scopes (because we would not have to add language for this case). It would also mean implementations do not have to worry about this case, which I'm thinking is extremely unlikely. If I try, I can come up with cases where somebody could conceivably try this - but I can't come up with a case where the pain of managing that sort of markup would be worth it. So, I think the options are - update the spec to explicitly cover this edge case (@keyscope on relcolspec means XYZ), or my preferred option, remove @keyscope from relcolspec. Thoughts? Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit ( http://www.dita-ot.org/ )