[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Filtering logic for <enumerationdef> element
|
Thanks Jeff for
the summary. Regarding item #2, I also believe it should be left out. I assume
that we if nobody asks for it to be re-added, we don’t need to discuss it
further, right? Su-Laine Su-Laine
Yeo JustSystems Canada, Inc. XMetaL Community Forums:
http://forums.xmetal.com/ From: Ogden, Jeff
[mailto:jogden@ptc.com] So, if I'm following this discussion correctly, this
issue is pretty much resolved: 1. The
feature as approved by the DITA TC stays in as part of DITA 1.2. 2. There
is still a question about a part of proposal being omitted from the draft DITA 1.2
spec. and what, if anything, we should do about that. Robert suggested
leaving it out of DITA 1.2. 3. We'll
try to come up with a better process for DITA 1.3. So what do we want to do about item #2? If the
omitted description was really part of the proposal that was approved by the
TC, is there a reason not to include it now other than that that is more work
for the 4th review and we are getting tired? To be legalistic, to leave
something out that was previously approved by a vote of the TC really requires
another vote by the TC. I guess we don’t have to be legalistic about
everything and I could live with this either way. Mostly we just need to
make a decision. -Jeff > -----Original Message----- > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] > Sent: Wednesday, January 06, 2010 11:26 PM > To: Eliot Kimber > Cc: dita > 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 > > >
--------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave
the OASIS TC that > generates this mail. Follow this link to all
your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]