Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 09, 2016, 07:29:20 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Choosing the right XML export schema  (Read 3386 times)

superticker

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 138
    • View Profile
    • Superticker's SU reviews about technology
    • Donate to Member
Choosing the right XML export schema
« on: November 19, 2009, 05:22:45 PM »
It would be great if The Form Letter Machine supported an XML schema export in either RSS 2.0 or iCalendar for online publishing of events listings.  The problem with some of these schemas is that it would be nice to extend them.  For example, some events (e.g. dances) have "locations" and "prices", but that's not part of the standard iCalendar or RSS 2.0 schema.  Those would be user-defined fields to extend these schemas.

So let's add a "create event" macro that allows a couple user defined variable fields.  The main body of each event can then be managed like TFLM would normally do (check boxes and radio buttons), but local event variables like %date%, %time%, %location%, %price% would be resolved independently for each event.  There should also be a check box to include/exclude each current/outdated event independently.

On XML export, either an RSS 2.0 or iCalendar feed can be created for the checked (enabled) events.  In addition, please include an hCalendar export, supporting microformats, that can be directly posted to a web page.

Perhaps the name of TFLM should be changed to "Extensible RSS Writer".  If there's already a product that can do this selectively like TFLM does, please post its URL.

-----

"Mini" Help & Manual application:  There's a mutually exclusive suggestion--unfortunately.  It might be desirable to employ a very rich XML schema to store TFLM's raw data.  Then its data file could be edited by other high-end tools such as Help & Manual, which uses the Darwin Information Typing Architecture (DITA) XML schema for technical documentation.  Unfortunately, this approach is an overkill for most users, and you would then need to employ an XSLT translation script to convert the DITA schema to RSS (or something) to make it usable for most people like Help & Manual does.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 36,421
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Choosing the right XML export schema
« Reply #1 on: November 20, 2009, 11:03:53 PM »
can you try to explain this a little more to me in terms of what you are suggesting i add, as simple as possible please :)

superticker

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 138
    • View Profile
    • Superticker's SU reviews about technology
    • Donate to Member
Re: Choosing the right XML export schema
« Reply #2 on: November 21, 2009, 01:54:18 AM »
can you try to explain this a little more to me
The goal here is to export an RSS 2.0 "event" feed (XML output) of upcoming events. A second goal is to export an hCalendar microformat output (XHTML/CSS output) that can be posted on the event calendar page of a website.

To accomplish this, the top folder level must define different events with required local variables like %date%, %time% (required for hCalendar) as well as local user-defined variables such as %location%, %price%, etc. for a given event.  A create-event macro can be use to create a new event at the root level and define its local variables.

A check box on each event folder (root level) can indicate if this event is active or inactive (pasted).  Only active events will be included in the exports. (Alternatively, it might be nice to group similar events together in root-level folders instead.  In this case, the event-level folders are just below the root-level folders.)

The subfolders in each event folder will work exactly like TFLM does today.  The only change is that local variable values (for a given event) take precedence over TFLM global variable values when they are resolved in the subfolders.

It would also be nice if the exported formats had the events sorted using the local event variable %date% and %time% as the sort keys.

Does this help make the proposed RSS Writer and microformat hCalendar Writer much clearer?  Did you need references?  I'm doing something like this today with the current TFLM, but without the hypertext tags that the RSS and hCalendar exports would include. I can send you that TFLM event tree if you like.
« Last Edit: November 21, 2009, 01:56:51 AM by superticker »