[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Question from keys review: addressing non-topicref elements in a map
I agree with all of this. 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 5/7/15, 2:27 PM, "Eliot Kimber" <ekimber@contrext.com> wrote: >I think that the last case is nonsensical, for the reason Robert gives: >topicref elements do not establish an ID scope the way maps and topics do >and therefore it's not meaningful to have an element ID on a keyref that >resolves to a topicref (meaning a keyref whose associated URI reference >resolves to a topicref). > >So I think in that case either the element ID is ignored or the case is >reported as a warning or an error and only the key name is considered for >resolution. > >I think that this is the same case as a reference to a key that is bound >to a non-DITA resource: there's no general way to map the token following >the "/" in the keyref to a fragment identifier for the target resource so >we simply don't recognize that case. > >For example, I'm at this moment implementing support for the svgref and >mathmlref elements and as part of that implementing support for resolving >key references. In that code any keyref of the form "foo/bar" where "foo" >binds to an SVG document or MathML document must ignore the "/bar" part >because resolving it in that context is not defined. If you want to >address a specific element within a document containing multiple SVG or >MathML elements you need to do it in the URI bound to the key, e.g.: > ><keydef keys="svg-01" > href="svg/svg-library.svg#drawing-01" > format="svg" >/> > >If this wasn't the case we'd have to either define how to map the second >part of keyrefs to fragments in all known or likely-to-be used formats or >define some general mapping rule and we certainly didn't do that in 1.2 >and I would not want to do so now--fragment identification details are >specific to each MIME type and DITA can only define the rules for >DITA-defined MIME types (DITA, DITAMAP, and DITAVAL). > >Cheers, > >E. >————— >Eliot Kimber, Owner >Contrext, LLC >http://contrext.com > > > > >On 5/7/15, 12:34 PM, "Robert D Anderson" <robander@us.ibm.com> wrote: > >>> As for what happens when you keyref to a topicref, the answer is, >>> whatever happens when you use a URI-based reference to a topicref in >>> that context. >> >>I think I phrased my question poorly. >> >>If I've got this: >>keyref="sampleKey/elementID" >> >>What does that resolve to when: >> >> >>* "sampleKey" is a topic? Should be clear - the element with >>id="elementID" inside of that topic >> >>* "sampleKey" is a map? I think we're saying now - the element with >>id="elementID" inside of that map >> >>* "sampleKey" is a topicref? This is my question -- is it the element >>with id="elementID" inside of that topicref? We don't scope ID's by >>topicref anywhere else, unlike topics. Is it the element with >>id="elementID" inside of the map that contains the topicref? That also >>seems painful. >> >> >>Robert D Anderson >>IBM Authoring Tools Development >>Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/) >> >>Chris Nitchie <chris.nitchie@oberontech.com> wrote on 05/07/2015 12:10:10: >> >>> From: Chris Nitchie <chris.nitchie@oberontech.com> >>> To: Robert D Anderson/Rochester/IBM@IBMUS >>> Cc: DITA TC <dita@lists.oasis-open.org> >>> Date: 05/07/2015 12:10 >>> Subject: Re: [dita] Question from keys review: addressing non- >>> topicref elements in a map >>> >>> <quote> >>> Currently you can reference that with: >>> keyref="chapter1" >>> href="#confused" >>> >>> If we remove the "non-topicref" elements, it would then state that >>> 'for references to elements within maps, the value of @keyref is a >>> key name plus slash plus element ID', which I think is incorrect >>> here -- because you just use the key name to reference this topicref. >>> </quote> >>> >>> No, you don't. You use the key name to reference the content >>> referenced by and/or text provided by that topicref, not the >>> topicref itself. To reference the topicref, you must specify its ID, >>> either in a keyref or URI-based reference. >>> >>> As for what happens when you keyref to a topicref, the answer is, >>> whatever happens when you use a URI-based reference to a topicref in >>> that context. >>> >>> Best, >>> >>> Chris >>> >>> > On May 7, 2015, at 12:56 PM, Robert D Anderson <robander@us.ibm.com> >>>wrote: >>> > >>> > Currently you can reference that with: >>> > keyref="chapter1" >>> > href="#confused" >>> > >>> > If we remove the "non-topicref" elements, it would then state that >>> 'for references to elements within maps, the value of @keyref is a >>> key name plus slash plus element ID', which I think is incorrect >>> here -- because you just use the key name to reference this topicref. >>> [attachment "graycol.gif" deleted by Robert D Anderson/Rochester/IBM] > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]