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<
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
Where is the knowledge we have lost in information?"
--T.S. Eliot
|
|
This email has been checked for viruses by Avast antivirus software.
|