Re: [dita-learningspec] Technical Comments on March 8 LC Declarations

[john_hunt@us.ibm.com]

Thanks, Elliot. 

These are very helpful comments. I generally
agree with all of them - my comments and recommendations to the SC are
below. 

1) on the "all elements should
have optional content" 

a) I think it's the case that in the
topic specializations, all elements are optional - I'll check to confirm.
Let me know if you notice any issues there.
b) Likewise for the metadata and map
domains - all are optional.
c) So, that leaves interactions, and
it looks like lcQuestion is the one element that is left required in all
of them, plus lcHotspotMap in lcHotspot. 

I agree with you - It makes sense to
make all the elements optional, for maximum flexibility, including in the
interactions. 

To the SC: Please review and
if there are any elements you DO NOT think should be made optional, let
us know.

2) Yes, I agree that an lcAssessmentBase
as you describe (or perhaps lcInteractionsBase) makes a lot of sense.  It
provides the easy open door for specializers to add custom interactions.

To the SC: I recommend to the
SC that we add this to the interactions domain.

3) Yes, I also agree on the learningBase.
Do I understand correctly that removing the shell removes this as a possible
topic type for authoring, but keeps it available as a base for additional
topic specializations? Again, makes good sense, and this concern has come
up in other comments.

To the SC: I recommend to the
SC that we do not include a "shell" for learningBase, thus not
making it available as an authorable topic type.

4) I also see no problem expanding the
available content for lcQuestion and lcAnswer, etc. The 1.2 container sounds
like a good approach.

5) And no problem making lcAsset repeatable,
as well.

To the SC: I recommend to the
SC that lcAsset be made repeatable.

Thanks again, Elliot. 

John
___________________________________
John Hunt
DITA Architect / Lotus Information Development Center
Chair, OASIS DITA learning and training content sub-committee
IBM Software Group/Lotus Software
john_hunt@us.ibm.com

From:	Eliot Kimber <ekimber@reallysi.com>
To:	dita-learningspec@lists.oasis-open.org
Date:	03/12/2008 06:47 PM
Subject:	[dita-learningspec] Technical Comments on Mark 8 LC Declarations

---

Based on an initial review of the doctypes in the
March 8 distribution I 
have the following comments on the declarations (as opposed to the 
abstract design):

- All elements that are likely targets for use via conref (which may be
all of them) should have completely optional content so that conreffing
elements do not have to include otherwise ignored subelements. There 
should not be an expectation that the standard types as declared will be
directly usable for authoring, or rather, the expectation should be that
appropriate constraints will be imposed via other means. The spec itself
should state in prose what the constraints *would be* if XML let you 
condition content rules based on the specification of an attribute.

- I would like to have an "abstract" base type from which all
the 
assessment types are derived so that it is possible to identify an 
assessment as an assessment without having to check it's specific type,
e.g.:

<!ELEMENT lcAssessmentBase
   ANY
 >
<!ATTLIST lcAssessmentBase
   class
     CDATA "+ topic/fig learning-d/lcAssessmentBase "
 >

And then specific types would be:

<!ATTLIST lcTrueFalse %global-atts;
     class
  CDATA "+ topic/fig learning-d/lcAssessmentBase learning-d/lcTrueFalse
"
 >

(This would be consistent with the existence of the learningBase topic
type.)

- Should learningBase have a shell? It seems to be an "abstract"
type 
that exists only to serve as the base for the more specialized learning
topic types (good) but it's not clear that it would ever be appropriate
to author directly at the learningBase level.

- Question and answer elements (e.g., lcQuestion, lcOpenAnswer) are 
currently specialized from "p". I know going in that this is
too 
restrictive--I have questions and answers that require multiple paras.
I 
think the more appropriate specialization base would be the proposed 1.2
"container" element. It would allow multiple paras (or even 
(%ph.cnt;)*|(%p.cnt;)*).

- lcAsset should be repeatable where it is allowed.

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