[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-lightweight-dita] Full DITA compatibility
So then you're suggesting we could define both the production DTD and an authoring DTD and guidelines on inferring from one to the other? As we're not developing the tools, this seems like a very new design approach indeed for the spec team. On Mon, May 11, 2015 6:08 pm, Don R Day wrote: > Whether the scope of a section could be derived from a heading; whether > a section wrapper needs to be reflected in the authoring interface (it > would not need to be if the scope of the section were represented by a > form field); whether title/body chunks are topics or sections, which > perhaps an author need not distinguish anyway... and the overall > observation that if we are looking at things from an author's viewpoint, > containing divisions are not always apparent anyway. My point is that an > authoring DTD can represent the parts that need to be made salient for > authors while still being a proper or inferrable subset of a more > complete model--a freedom of design that we can take advantage of. > > On 5/11/2015 10:21 AM, Noz Urbina wrote: >> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]