Easy specialization options

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

Trimming down and renaming the thread to
focus on this one aspect. 

Fredrik wrote:
> And finally, the more I think about it, the more
I realize that for this
> initiative to really work well we should make creating specializations
as
> simple as possible. Similar to how web cms?s allow to create different
> page types by combining different component types in some kind of
ui, this
> should be a task that anyone can do without DTD/XSD/RNG knowledge.
Perhaps
> this is an area where us tool vendors can help out, but for that to
be as
> successful, it helps if it is conceptually as straightforward as possible.

I replied:

> Re making specializations easier: I couldn't
agree more. This is something
> I really want to include in the initial spec. The two main approaches
> we've talked about are:
>
> 1 - a specialization for authoring specializations: you document the
> specialization in a topic (or several topics and a map), then generate
> from there - including schemas (DTD, RNG, XSD), documentation, etc.
> Authoring tool vendors would be able to create their own support for
the
> specialization, generating whatever artifacts they require in addition,
> like authoring templates/guidance.
>
> 2 - or specialization by example: you create a sample of the kind
of topic
> or map you want to create, then annotate it with attributes to identify
> specialization, potentially additional attributes or elements to make
> complex content models explicit (like when you're showing one example
but
> there are several valid but mutually exclusive options), and then
generate
> from there - schemas again (DTD, RNG, XSD), maybe documentation (this
> would be harder I think), and authoring templates (this would potentially
> be easier).

And Noz replied:

>I spent a long time in DITA 1.1 thinking about
the two approaches you
>describe and want to say that my definite preference is option 2. Ideally,
>the experience should be as much like saving a template as possible.
In
>other words, you take any topic (including already specialised ones)
(and
>maybe set something at the root that tells the editor to open up the
model
>into a 'specialisation mode') and then you can create a target structure.
>Then you save, hit 'go', and then you have a 'template' that other
authors
>can then be contrained by.
>
>IMHO, mimicking the logical flow of more common tools will vastly improve
>adoption of this ability of DITA.

My concern with the template approach
is how to capture details like the actual content models of the elements.


For example, if your template says:

<mynewsection>
        <p>Something
here</p>
        <ul>
         
      <li>And here!</li>
        </ul>
</mynewsection>

What's the content model for mynewsection?

It could be (p, ul) or (p |ul)*, or
(p?, ul?), or... etc.

Maybe we could capture it with a specialized
<data> element?

Another possibility would be to use
the example-based approach for rapid prototyping - generate a doc shell
with element stubs, which you then fill out in separate files to get to
a completely described and generatable model. But that takes us farther
away from being like a template.


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