[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Filtering logic for <enumerationdef> element
Eliot, that's a brilliant way of looking at it. I've gone from being depressed about this feature to actually being excited about it. Cool! :) Su-Laine Su-Laine Yeo Solutions Consultant JustSystems Canada, Inc. Office: 778-327-6356 syeo@justsystems.com www.justsystems.com XMetaL Community Forums: http://forums.xmetal.com/ -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Wednesday, January 06, 2010 3:08 PM To: Su-Laine Yeo; dita Subject: Re: [dita] Filtering logic for <enumerationdef> element On 1/6/10 4:35 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote: XMetaL > does have a way to get a picklist of values into the authoring interface using > DITA conditional processing attributes without specializing DITA (go to > C:\Program Files\XMetaL 6.0\Author\Conditional Text\configs and edit the text > file named ct_config.xml). It doesn't do everything that the Subject Scheme > Maps feature prescribes, but it does the basic thing, which is define a list > of allowed values that then appear in checkboxes in the UI. Since the transform to generate the ct_config.xml file from a subject scheme map would be, if not trivial, then at least easy to do, I would say that XMetal *already* supports it since you would be able to have it implemented between the time somebody asked for the feature and when you could build your next maintenance update. There's nothing that says a tool has to use a subject schema map directly or dynamically to get lists of values. It simply serves as an *interchange* representation of a set of values. If an editor today has some sort of dynamic enumeration configuration mechanism, that mechanism can be used from subject scheme maps via transforms, at the very minimum (and those transforms could, of course, be applied dynamically, if necessary). As for implementations other than IBM's: I use subject scheme maps pretty heavily to represent client metadata and classification taxonomies, of which part is generating UIs that reflect the terms defined in the subject scheme. I have various transforms that take subject scheme maps and generate various things from them in order to reflect the taxonomies in various processing and interaction environments. For example, I have a pretty simple XSLT that can take a subject scheme map and generate a script that then creates in our RSuite CMS product a "dynamic browse tree" that is a tree of queries, one for each subject, reflecting the subject hierarchy (where the subject scheme reflects metadata in topics and maps managed by the repository). Likewise, I have code that can generate, from the same subject scheme map, JavaScript code that builds a selection tree UI component (for setting metadata values during authoring, for example). I can also generate forms configuration for use with an XForms-based forms generator. Because we (the community of DITA implementors) have lots of infrastructure for working with complex maps fairly easily the fact that subject scheme maps use keys and can take advantage of map composition features and whatnot shouldn't really be an issue because there's already publicly-available software that handles all that complexity automatically (the Open Toolkit, stuff I've released through DITA For Publishers, etc.). Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]