Discussion of keyref alternative for phrase conrefs

Michael, I want to drill into implications of the proposal you
    reminded us of at this morning's call: to use limited conref for
    structures, but use keyref for phrases. This makes some sense but
    has implications for RESTfully addressed endpoints (the primary
    application space I see for LwD).

    

    In REST, everything is either a resource or a collection of
    resources. Search results are a collection of resources, as are
    bookmarks or any list of links created for any purpose. Maps are a
    special case of "links with a curated context," but these turn out
    to be far less common for Web-based interactions than content that
    was arrived at by search (to reify Mark Baker's general observations
    that Every Page is Page One).

    

    Thus for dynamically accessed DITA topic resources, the problem is
    how should keyrefs be associated with a resource that happens to be
    accessed without a curated context (that is, an intentionally
    authored ditamap with keyrefs that pertain to that context). This is
    probably not unique to expeDITA; I imagine that Jang's renderer must
    need to deal with the context problem as well.

    

    From my discoveries with expeDITA, I've decided that topicrefs themselves
    are tantamount to first-class managed resources because they are
    proxies for the resources they describe (which in the expeDITA
    universe can be any text or media resource, if we are to be
    consistent in using DITA features for resource management). By
    extrapolation, I'm proposing that keyrefs likewise be
    regarded as first--class managed units that can be either authored
    by determination into a map (conventional DITA Way) or associated by
    property into any non-curated collection (alternative DITA Way). And
    association by property, in the absence of a curated map, is also
    the best way to ensure default completeness for a resource access
    without map context.

    

    In practice, I've been using conrefs sparingly; once you've built
    the transclusion transform, there is no reason why they could not be
    used everywhere, even for phrases. But the requirement to name the
    source for the conref becomes a burden for authoring, particularly
    in an unassisted forms editor. If topics permitted conref sources to
    be named in the prolog, we could resolve otherwise indeterminate
    context from that declaration. And by the same reckoning, that goes
    for maps that hold preferred keyrefs for otherwise indeterminate
    context.

    

    Hoping these thoughts can spur some discussion towards a design
    direction for  LwD.

    

    (The other recent 'Well duh" realization I've had is that xref can

    be specialized to represent form input/textarea markup, which is
    rooted in the observation that xref title resolution is already
    implicitly conref-like from a DITA PoV, and equally query-like from
    an SQL PoV--you've effectively referenced a resource in a database
    as the value="" part of the field! Suffice to say that a DITA
      topic can be authored to represent a form for a login or a
    simple topic editor (yes, it could edit itself), as long as you
    provide logic for the form. I hesitate to suggest xref in place of
    keyref but only because xref seems to need a fully qualified
    href/querystring. More later as I work up a substantive demo.)
    
-- 

      
      

        Don R. Day

        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 
      

    

  

	

		
			
				
			
		
		
			

				This email has been checked for viruses by Avast antivirus software.
				
www.avast.com