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


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

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

Subject: Some belated notes from last week's meeting

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

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