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.
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 knowledge we have lost in information?"
--T.S. Eliot
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 |