Re: [xsl] RDF graph to SVG force-directed layout

["Martynas Jusevičius martynas@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Liam, Paul,

yes we looked into d3.js in the first place, but decided to attempt a
native XSLT implementation which would integrate better with the rest
of our UI code.

But if we cannot make the performance more satisfactory, we might need
to try d3.js again.

On Thu, Oct 15, 2020 at 3:16 AM Paul Tyson phtyson@xxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I also thought of d3.js, but donbt know if it fits your overall
architecture or data flow.
>
> Years ago I experimented with json-ld from fuseki into a d3 client that
rendered very nice graphs. It showed great promise. But as it had no xsl, that
solution would be off-topic for this list.
>
> Regards,
> bPaul
>
> > On Oct 14, 2020, at 17:37, Liam R. E. Quin liam@xxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > o;?On Wed, 2020-10-14 at 21:01 +0000, Martynas JuseviD
ius
> > martynas@xxxxxxxxxxxxx wrote:
> >> Hi,
> >>
> >> could anyone suggest any optimizations to this stylesheet that
> >> transforms a graph encoded as RDF/XML to an SVG directed graph
> >> layout:
> >
> > without looking in detail - are you able to use d3.js in the browser to
> > do the fotce calulation part? It might not be faster but watching the
> > SVG objects  move  gradually into equilibrium has its own fascination.
> >
> > Most of these algorithms are likely to be at best O(nB2) C Niterations,
> > so there's some inherent  slowness.
> >
> > Looking slightly more  closely -
> > * consider using xsl:iterate instead of a recursive template at line
> > 282;
> > * run the stylesheet on the command-line and have Saxon write out
> > profiling information to see where the time goes
> > * add as= to any templates * variables that don't already have them
> > * use on-no-match="shallow-copy" on an xsl:mode declaration for
> > ac:SVTPositioning and delete the template on line 303
> > * consider using maps rather than elements during positioning, as
> > creating DOM elements in a browser is likely to be slow
> >
> > But an algorithm with worse than n^2 complexity is always likely to
> > have problems as n increases - the trick (as with e.g. QuickSort) is to
> > remember complexity is usually an average best case, and find values
> > for which the algorithm does better. E.g. removing nodes from
> > consideration when they stop moving under a certain amount each time.
> >
> > Liam
> >
> >
> > --
> > Liam Quin, https://www.delightfulcomputing.com/
> > Available for XML/Document/Information Architecture/XSLT/
> > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> > Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org