Some belated notes from last week's meeting

[Michael Priestley <mpriestl@ca.ibm.com>]

We had light attendance, but had some good
discussions around table and specialization models.

Domain status reports:
- no status from any area this week
- hopefully better luck next time?

DTD update status:
- Mark Giffin is beginning updates to
narrow the doctypes down to just topic and map
- question whether to make shortdesc
required or keep it optional: consensus on call was to keep it optional

Table model discussion:
Lots of discussion, but summed down
to:

- we at least need title
- so let's add back in fig, with simpletable
in its content model
- we can also consider specializing
simpletable to use element names similar to HTML5

Open question: 
- assuming fig will also allow video,
audio, pre, etc. - do we want to make those elements ONLY available through
fig, to simplify the content model?
- this would give people a shorter list
of elements to navigate, but they'd need to add an extra level of container
for a lot of things that they might not always want
- [reviewing this as I write it up,
I think I'm leaning towards having fig as an optional container, and allowing
simpletable etc to be created outside fig as well]

What about content types/domains that
require full table?
- we talked for ages about how/whether
we could get HTML tables in, or specialize simpletable to allow colspan/rowspan
- but if we want compatibility with
full DITA, full tables mean CALS tables
- this is a reasonable place for a domain
like marketing, for example, to swap out simpletable for full table in
their content types
- full table wouldn't be part of the
basic topic/map starting point, but it could be included in the example
content types for domains that want it

Rob Hanna has a paper to share that
includes discussion of defining custom table layouts during output processing,
rather than having the author define it. In other words if the table is
semantic and has a repeating structure, like choicetable in full task,
then colspans can be created by the output process without involving the
author in a layout decision.


Specializaton model:
We focused on discussing the template
model proposed by Don and Noz

We could potentially just have a specialized
data element that becomes available in template authoring mode; it would
provide the details for its parent, identifying it as a specialized element
and defining its content model.

The one challenge with template-based
specialization authoring is any content model with an exclusive OR. For
example, general task in DITA allows either <steps>, <steps-unordered>,
or <steps-informal>; but you can't create a valid example task that
includes all three. 

That might be ok, though, if we're willing
to accept that the template won't be a valid instance of the thing it describes.

I'll try to send a follow-on note with
a more detailed example.

Michael Priestley, Senior Technical
Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley