Re: [dita-lightweight-dita] Full DITA compatibility

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

What specifically would be in the authoring DTD vs Production in this
discussion? I'm not clear.


On Mon, May 11, 2015 4:21 pm, Don R Day wrote:
> It may be useful during this discussion to keep in mind the distinction
> between an authoring DTD and a production DTD. The authoring DTD
> represents the necessary aspects of the information model that a writer
> needs to be concerned with; in many ways it describes the ideal
> authoring experience (where I will plug Rick Yagodich's useful book
> Author Experience) that dovetails into (but doesn't surface) the more
> arcane requirements of the underlying information model in the CMS.
>
> Much of this discussion seems to be about the authoring model, and that
> is fine as long as we keep that model separate from the underlying
> information model (to avoid saying data model, which is more accurate
> but not in the typical marketer's vocabulary).
>
> On the other hand, after we've discussed this idealized authoring model,
> will the representative deep information model be at all satisfying to
> the actual business requirements of the organization, and will all
> constituencies buy into it?
>
> This begets a hard question: can we ever get XML into the typical tools
> that support Web-based organizations?
>
> To be honest, selling XML is itself like selling fly strips, which are
> still useful but out-convenienced by dozens of more visually appealing
> JavaScript-based alternatives. The ideal role for XML may lie in
> defining the relationship between the authoring model and the actual
> systems where users will be storing their data, which is largely in
> field-oriented databases rather than file systems. XML defines and
> guides the templates; the DITA processing logic itself gets transferred
> to libraries that enable existing CMS publishing systems to emulate DITA
> behaviors that are described in terms that have value to Web
> programmers: reuse of components and the ability to apply
> personalization/adaptation to content requests (and perhaps
> others--these need to be teased out as DITA's value-add to the Web
> production stack used by marketers).
>
> By the way, I totally agree that HTML5 should still consider the role of
> an unleveled heading. My preference would be for <label> which could
> then be used in fig, section, table, and other places where our HTML
> transforms have crudely mapped to an H5 or a bolded paragraph for lack
> of better match on the HTML side. The presence of <figcaption>in HTML5
> justifies the general concept; they just need to get it into more
> contexts where it can be used the same way--to label chunks that are
> inline, not hierarchical. Off my soapbox now.
> --
> Don
>
> On 5/11/2015 5:55 AM, Joe Pairman wrote:
>> Cheers Noz. Just two quick clarifications before I need to leave the
>> thread for now:
>>
>>> I think that having users set whether a title is a title for nav or not
>>> is
>>> a simple work-around. Although that doesn't really fit well
>>> semantically
>>> into @chunk (not that @chunks is particularly clear or straight-forward
>>> at
>>> the moment. @chunk=to-self could turn on titles in nav? I'm just
>>> riffing
>>> here).
>> Where there were a need for authors to manually switch on/off navigation
>> for specific nodes, something along those lines makes sense. As a
>> general point, though, it's always been up to implementors how to define
>> these kinds of navigational / presentational rules, and Lightweight DITA
>> doesn't attempt to constrain that side of things further (at least if
>> I've understood the initiative correctly).
>>
>> (I'd started talking about navigation as an illustration of the intent
>> of <section>. While you *could* get section titles into navigation, it
>> seems like going against the grain, and you'd still be prevented from
>> nesting sections.)
>>
>>>> Of course the tradeoff is that you can't then easily reorder the
>>>> nested
>>>> topics to suit a particular output context...
>>> There's no problem with reordering nested topics provided the parent
>>> topic
>>> content doesn't move...
>> Right. I just wanted to point out that the tradeoff of keeping child
>> topics in the same storage object is that you have to edit the CMS
>> object / file to reorder them. If you're doing it for a specific output
>> context only (re-ordering for a particular audience segment or product,
>> perhaps), it means duplicating the object in some way. When each topic
>> is a separate storage object, you can re-order topics in a specific map
>> for that output context.
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>


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

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