Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Tracing Paths (Read 4578 times)
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Tracing Paths
Aug 08th, 2011, 5:44am
 
The idea arises from discussion in this thread.

New action code feature idea: tracePath(startItem).direction.linkType.[$AttrName].  

This would mimic some links() syntax and would only work with a non-branching path; I envisage the process would halt if/where there was more than one onward/backward path choice. Failure on onward path ambiguity would enable diagnosis and triage of incorrectly ambiguous paths. sure, I can see some being interested in branching paths but my hunch is the back-of-house works gets a lot more complex/expensive compared to single path.

startItem. An evaluated input resolving to a single unique note name/path. This allows for more flexibility as a given link type might be used for more than one path - as long as they don't cross (or branch). Default value: this.

direction. outbound/inbound. Default value: outbound. I do think backwards trace as well as forwards is important though. I love the map enactment on paths but I remember my first comment when testing the feature was "how do I trace backwards"). Going somewhere is normally deliberate; seeing where we came from/how we got here can be less obvious. Being able to walk back along a path is thus useful. If much more difficult to engineer, I guess I'd settle for outward-only (for now!).

linkType. Same usage/syntax as for links().

$AttrName. Same as for links() except the default is $Path. I suggest $Path as default rather than $Name as a likely use would be as a nested group argument for links() like in the scenario discussed in the thread linked to above. However, this could collect any attribute, like links().

Output. List-type data. The output would always be in path order in the input-specified direction (i.e. out/inbound). Unlike links() the startItem's data would be included - i.e. providing data for every member of the path.
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Paul Walters
Full Member
*
Offline



Posts: 267

Re: Tracing Paths
Reply #1 - Aug 8th, 2011, 8:56am
 
I like the objective, but I think this would be devilishly difficult to work with in practice.  Over here, I rarely have a map with non-branching paths.  So tracePath would usually fail for me.  Then, how do we know it failed, and how to diagnose/repair failure?

I realize all the data needed is in the TBX file in the <links></links> section.   If we could somehow access, via action code, the "sourceid" and "destid" element values in that section (which I assume View > Paths, and other features, does) then that would be very valuable data for this path-tracing.
Back to top
 
 
  IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Tracing Paths
Reply #2 - Aug 8th, 2011, 9:42am
 
There are some graph-theoretic approaches to dealing with branching paths, so in principle we could accommodate them.

In practice, explaining them to everyone might be a challenge. Things get even more complicated if the path contains cycles.  And if the path is not connected -- if more than one note has no inbound links on the path, so the path has several distinct beginnings and endings -- things are complicated in a different direction.

(What I'm thinking here, for those who remember their graph theory from their schooldays, is returning a topological sort of the spanning tree of the designated link graph.)
Back to top
 
 
WWW   IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Tracing Paths
Reply #3 - Aug 8th, 2011, 9:50am
 
[parallel postings - this was in reply to Paul's last]

We're talking about different things. To cut complexity (and barriers to implementation) the proposal is, quite deliberately, to trace non-branching paths. Ergo it would not trace branching paths - a much more complex scenario (multiple outcomes, correctly detecting looping paths, etc.). However, not being able to trace branching paths is not a reason for rejecting the simpler possibility of being able to trace non-branching paths. Not everyone having the same needs; for instance, a tracePath() would solve Sumner's scenario.

The proposed failure - silent or otherwise - does work (conceptually) as intended, given we're only tracing single paths. If a path of link type 'x'  from A links to B, B to D and, D to E which then links to both C and F, then my proposal would return paths to A/B/D/E but not the full path. It stops at E as there is more than one onward type 'x' link.

Perhaps tracing branching paths is really best considered as a separate proposal. I'm not pushing a case here, but just floating an idea. Indeed, the need is not mine, but I can see the current action code problems of some other users could be addressed by the proposal. Plus, I figure something less ambitious and easier to implement/test is a more likely candidate for adoption than more complex link traversal tools - nice as the latter would be.  Smiley
Back to top
 
« Last Edit: Aug 8th, 2011, 9:51am by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Sumner Gerard
Full Member
*
Offline



Posts: 359

Re: Tracing Paths
Reply #4 - Aug 8th, 2011, 6:31pm
 
tracePath... would be convenient for "geo" mapping, especially since one could specify the startItem.

For other purposes was thinking it would be useful also to be able to specify endItem and return a links path if one exists. Or, if that's too complicated, then "just" a PathExists boolean. In a complicated TB map with lots of links and notes it can be useful to be able to test whether startItem and endItem are somehow indirectly linked, and, if they are, go hunting visually for the path(s).

Would guess that would be really tough to implement, though. Too many possibilities to search through. And the complexities of branching and loops and cycles mentioned here are beyond me, too.

Meanwhile it would be convenient––and would seem logical––for the existing links()... operator to return the set (or is it a list?) ordered in the same way as is currently displayed in Paths View... i.e., in the order one sees listed in the right panel (at least one does with the example in the other thread) when a link type is selected on the left in the view and also appears as 'path name' lower right.
Back to top
 
« Last Edit: Aug 8th, 2011, 6:33pm by Sumner Gerard »  
  IP Logged
Pages: 1
Send Topic Print