Technical Comments on Mark 8 LC Declarations

[Eliot Kimber <ekimber@reallysi.com>]

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