How are include nodes treated?

[scripting]

I'm working on a reboot of the worldoutline, in Node of course, and one of the first things I'm looking at are include nodes.

It appears that opmlparser expands them. That is, when it encounters an include node, it reads the file and adds it underneath the including headline as if it were part of the outline.

The attributes are passed through so the application can tell it was an included node (if it wants to reload it periodically, so it can account for changes in the outline while the worldoutline software is running.

It seems to me it would be best if there were an option to not expand them. The worldoutline would set that flag false, because the idea is the virtual outline could be infinite, could contain circular references, for example, or could just be really huge. ;-)

[danmactough]

It appears that opmlparser expands them.

We don't expand them. For all the reasons you noted you might not want to: virtual outline could be infinite, could contain circular references, or could just be really huge. :smile:

You can see an example of how include elements get parsed by doing this:

cd <some project that uses opmlparser>
curl --silent http://hosting.opml.org/dave/spec/placesLived.opml | node_modules/opmlparser/bin/dump.js

Output:

{ text: 'Cambridge', '#id': 3, '#parentid': 2 }
{ text: 'West Newton', '#id': 4, '#parentid': 2 }
{ text: 'Boston', '#id': 2, '#parentid': 1 }
{ text: 'Mountain View', '#id': 6, '#parentid': 5 }
{ text: 'Los Gatos', '#id': 7, '#parentid': 5 }
{ text: 'Palo Alto', '#id': 8, '#parentid': 5 }
{ text: 'Woodside', '#id': 9, '#parentid': 5 }
{ text: 'Bay Area', '#id': 5, '#parentid': 1 }
{ text: 'Uptown', '#id': 11, '#parentid': 10 }
{ text: 'Metairie', '#id': 12, '#parentid': 10 }
{ text: 'New Orleans', '#id': 10, '#parentid': 1 }
{ text: 'Madison', '#id': 14, '#parentid': 13 }
{ text: 'Wisconsin', '#id': 13, '#parentid': 1 }
{ text: 'Florida',
  type: 'include',
  url: 'http://hosting.opml.org/dave/florida.opml',
  '#id': 15,
  '#parentid': 1 }
{ text: 'Jackson Heights', '#id': 17, '#parentid': 16 }
{ text: 'Flushing', '#id': 18, '#parentid': 16 }
{ text: 'The Bronx', '#id': 19, '#parentid': 16 }
{ text: 'New York', '#id': 16, '#parentid': 1 }
{ text: 'Places I\'ve lived', '#id': 1, '#parentid': 0 }
{ '#ns': {},
  '@': {},
  '#xml': { version: '1.0', encoding: 'ISO-8859-1' },
  '#type': 'opml',
  '#version': '2.0',
  title: 'placesLived.opml',
  datecreated: Mon Feb 27 2006 07:09:48 GMT-0500 (EST),
  datemodified: Mon Feb 27 2006 07:11:44 GMT-0500 (EST),
  ownername: 'Dave Winer',
  owneremail: null,
  docs: null,
  expansionstate: '1, 2, 5, 10, 13, 15',
  vertscrollstate: '1',
  windowtop: '242',
  windowleft: '329',
  windowbottom: '665',
  windowright: '547',
  ownerid: 'http://www.opml.org/profiles/sendMail?usernum=1' }

[scripting]

Well, you are right. I think what happened is that I left an include node expanded, and its subtext leaked out into the OPML. At least my current editor seems to have that bug. I haven't tracked it down yet. I concluded incorrectly that OPML Parser was diving into the includes. Sorry for the confusion.

I wrote a standalone app to test it, and in it there's a routine that loads an OPML file into a JavaScript object. Sometimes I just want the data in the OPML file, as in River4, but in other projects I want the structure. That's what readOpml in this Gist does.

https://gist.github.com/scripting/d0c898357424c30a2724

I wanted to share it here, so others might find it. It's pretty useful.