OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]