Re: [dita] DITA 2.0 planning: What the deprecated query attribute means to future DITA

Given that a URI can both be a query (via a defined REST API that uses the resource part) or can contain a query (using the "?" part of the URI) I think a separate @query attribute cannot be justified as it's clearly both redundant with functionality inherent in URIs and implies a DITA-defined query mechanism, which we absolutely do not want to pursue.

However, it could be useful to define new values for @format that indicate the nature of referenced resource, namely that it is either a single, dynamically-determined resource or a dynamically-constructed map (what Don generalizes as "collection" in Web terms).

It seems reasonable to not require processors to examine the URI details to determine what the resolution requirements or expectations are for a given topicref.

On the other hand, all URIs are, ultimately, dynamic, in that just because you write "foo/bar/myfile-right-here.dita", there's no guarantee that whatever resolves that URI will not do something completely dynamic. The only requirement in XML generally is that the same URI reference to a document will return the same result in the same processing instance (e.g., within the scope of a single XSLT run).

So the system is already inherently dynamic and DITA doesn't really change that. 

But that said, I think it would be useful to add a little codification around how authors can indicate the intent to use explicitly-dynamic references in order to make author intent clear and to provide better guidance to system implementors.

Cheers,

E.

----

Eliot Kimber, Owner

Contrext, LLC

http://contrext.com

From:  dita <> on behalf of Don Day <>
Date:  Tuesday, May 17, 2016 at 12:09 PM
To:  dita <>
Subject:  [dita] DITA 2.0 planning: What the deprecated query attribute means to future DITA

    

  

    
I am forking this particular concept from the "deprecated
      elements" thread as a separate discussion that introduces a
      principle for 2.0 consideration.

    

    
The spec deprecates the @query attribute of topicref. In
      practice, we've never developed best practices for it, hence it
      has been regarded as baggage in the design, and I won't lay down
      in the road over keeping it in that form. We need it, but it is in
      the wrong place.

    

    
We tend to have a deterministic focus on managing the artifacts
      named by a topicrefs @href. In a sense, the controlling viewpoint
      is "topicref as a CMS feature" to the exclusion of "topicref as a
      pointer to a collection," which is much less deterministic from a
      build point of view.

      

      The query attribute should remind us that the Web represents a
      RESTful CMS that sees the universe of content as either collections
      or resources--everything we do is about accessing one
      or the other. In "map build" publishing, every endpoint is an
      accounted-for resource, usually guaranteed by a backend CMS. If
      our production and delivery systems behaved more like the Web, a
      "topicref-as-query" could resolve dynamically to SQL's 'LIKE'
      operator, which can return 0 or more matches. From that
      viewpoint,  we use maps as a named collection of absolute
      endpoints, and a mapref is actually a query for other named
      collections. 

    

    
To change viewpoints, think of the CMS as a browser's search bar
      in which a search for all "things of a kind" (category, author,
      substring, xpath part, etc.) results in an anonymous map of
      endpoints. If we saved that result set, it would effectively
      become a named map and a new managed resource in its own right. In
      that sense, the query is essentially a mapref for a dynamic rather
      than deterministic set of returned resources.

    

    
So for DITA 2.0 I'd like to see a closer practical alignment with
      the Web's RESTful addressing model in order to enable both build
      (deterministic) and query-driven (non-deterministic) applications.
      In principle, our designation of URI as the href's type should be
      a good starting point. The missing piece is "how does a URI
        path appear and behave if there is not a named resource at the
        end of it?" The resolution of this principle fundamentally
      drives all use of collections in Web addressing and processing. It
      may profoundly affect the role of key definitions when the context
      is a query rather than a named collection.

    

    -- 

    

      Don R. Day

      Founding Chair, OASIS DITA Technical Committee (current version: DITA
        1.3)

      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

      

    

    
On 5/17/2016 9:37 AM, Kristen James
      Eberlein wrote:

    

    Also, are there elements like <topicsetref> that
      do not add value/are duplicates and should be removed?
      

      

      Or little used features or functionality that do not add
      sufficient value and should be considered for removal?
      

    
    

    

    

  

	

        
		Virus-free. www.avast.com