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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-learningspec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita-learningspec] FW: [dita] DITA 1.2 packages [updated yetagain]


As such, I'd recommend that we keep the number of elements that an editor would present to a user down to a minimum with the specialization. I don't think we expect all of our users to be doing software or technical training, so why expose the tags to them?

They are easy enough to add in a local shell, so why not take a minimalist approach with the base shell?

Best regards,

--Scott

Eliot Kimber wrote:
On 4/23/08 9:01 AM, "Patrick Quinlan" <Patrick.Quinlan@citrix.com> wrote:

  
My gut reaction is yes, those domains should be included, but I guess
I'm not clear on what the alternative looks like. If the shells do NOT
include those domains, what has to be done in order to use elements like



*         codeblock

*         filepath

*         userinput

*         uicontrol



We plan to use them, and I imagine other groups writing training for
software would.
    

You would need to create your own local shell (which you should do anyway as
a matter of standard practice) and integrate those domains (e.g., by copying
the appropriate declarations from the all-inclusive shell that will be part
of the standard DITA 1.2 declaration set package).

It's important to remember that the shells provided the by DITA TC are
nothing more than a convenience--anyone using DITA in production should be
making local shells as the *first step* in setting up their production
environment.

I would also suggest that in the case of the Learning Content specialization
in particular, it seems highly likely that most users will be creating
specializations simply to provide friendlier names for learning content
elements since the "lc*" names are appropriate for the standard declarations
but not that nice for end users authoring content.

This is what I've done for my test prep client I would do it for any other
learning content client who didn't specifically tell me not to.

This means that any standard shell provided for the Learning Content stuff
is even less useful then the base DITA shells because it's likely not going
to be even relevant as a base for configuration.

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.  You may a link to this group and 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]