Re: Easy specialization options

["Noz Urbina" <noz.urbina@urbinaconsulting.com>]

I had decided you'd need something like a specialised data element or a
set of special attributes:

> actual content models of the elements.
>
> For example, if your template says:
>
> <mynewsection>
>         <p model="ORset" quantity="1plus">Something here</p>
>         <ul model="ORset" quantity="1only">
>                 <li>And here!</li>
>         </ul>
> </mynewsection>
>

Meaning one or more Ps or 1 UL are allowed in the new section. The scope
would tell you the scope of the ORset.

Etc.

I would need someone better with DTDs to flesh out a whole vocab.
Alternatively, a special <data> elem might be able to accommodate more
flexibility without having to mess with attributes. You could also add IDs
and specify specifically which elements you were talking about and the
relationship with those elements.

Noz

On Fri, June 19, 2015 7:37 pm, Michael Priestley wrote:
> 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
>


-- 
Noz Urbina
Content Strategist and Founder, UrbinaConsulting.com

Author, "Content Strategy: Connecting the dots between, business, brand,
and benefits" http://thecontentstrategybook.com