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