[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Need Clarification on Implications of Different List Markup Patterns
Hi Gershon, I think there are actually two issues here: - The base topic type, and the standard concept and reference specializations, are too LOOSE to directly enforce good markup practices - In contrast, the standard task specialization is actually too SPECIFIC to fit most organization's internal standards and legacy content What I would like the committee to consider is: - Keeping the base topic and standard specializations loose enough to fit a variety of actual legacy data and internal standards, while still enforcing the basics of DITA - Developing tighter "best practices" specializations of these that can serve as a role model for good markup, and that might also be used for new content vs. legacy content What I think we DON'T want to do is to make the base spec so tight that it makes adopting DITA a matter of having to rewrite all your content immediately, or of being forced to accept a particular idea of "best practices" writing that may not match your own. This "two-tier" approach could potentially give us the best of BOTH worlds. Eric Eric Severson Chief Technology Officer, Flatrions Solutions Corporation Eric.Severson@FlatironsSolutions.com 303-542-2125 Flatirons Solutions Corporation -----Original Message----- From: Gershon L Joseph [mailto:gljoseph@yahoo.com] Sent: Tuesday, February 12, 2008 10:37 AM To: Eliot Kimber; dita@lists.oasis-open.org Subject: Re: [dita] Need Clarification on Implications of Different List Markup Patterns Hi Eliot, I see no-one responded yet. I think what you're seeing is an issue I've been complaining about for ages -- the default topic types are too loose to use as-is, and authors tend to mark up using worst-practice XML instead of best-practice. I now recommend all my DITA clients to specialize the base topic types to remove mixed markup wherever possible, and to enforce best practice XML (and SGML for that matter) DTD modeling techniques. The result is that table entries, list items, etc. all contain <p> or some other block content, since I don't allow #PCDATA directly in <li> or <entry>. I still feel that the DITA spec should provide a loose set of DTDs for users to specialize from, but that it should also provide a tight set of DTDs that authors can use out of the box. IMO the current base topic DTDs are too loose to be useful. The sad fact is we see tons of users applying bad markup -- effectively marking up their DITA XML content the way they applied styles in Word or FrameMaker. Maybe this is something the TC could (should?) take up post-1.2. I don't think the spec can address the issue via language alone -- formatting is largely an implementation issue that's beyond the spec. However, I do feel the spec should provide new DITA users a set of tight topic DTDs that force tight markup. This would actually make it easier for new users to migrate to DITA. Gershon Gershon L Joseph Director of Technology and Single Sourcing Tech-Tav Documentation Ltd. Secretary, OASIS DITA Technical Committee Secretary, OASIS DITA Translation Subcommittee Member, OASIS DocBook Technical Committee +972-8-974-1569 (direct) +972-57-314-1170 (mobile) http://www.tech-tav.com ----- Original Message ---- > From: Eliot Kimber <ekimber@reallysi.com> > To: dita@lists.oasis-open.org > Sent: Tuesday, February 5, 2008 5:36:54 PM > Subject: [dita] Need Clarification on Implications of Different List Markup Patterns > > I'm trying to do a little implementation work on the DITA2InDesign > processor and worked yesterday on implementing the mapping of list items > to the appropriate InDesign paragraph styles. > > Because InDesign has a weak notion of containment, each level of a list > has to be mapped to a different paragraph style that defines the > formatting details for that level (e.g., 2nd-level numbered item within > 1st-level numbered item). > > In trying to work out the rules I realized that the 1.1 spec is silent > on what the implications of these two markup patterns are: > > > > and > > > > Both are allowed. > > The question is: should the intervening element establish a new list > sequence or should the list sequence continue from the nearest > containing list element? > > In a similar vein, there is inconsistent implementation behavior for the > presentation of list items that do and don't start with nested > elements between the Toolkit's built-in HTML renderer and the PDF2 > renderer. This has been discussed before on this list. > > But I think a formal decision needs to be made about what the intended > implications, if any, of nested elements within are, even if > the intent is "rendering effect is implementation defined". > > My personal opinion is that the current HTML formatting implementation > is incorrect and that should always be rendered the same regardless > of whether it has an initial or not. If there is a requirement to > distinguish compact from non-compact lists (which is the practical > effect of the HTML behavior [but not the PDF behavior]) that would be > better handled with either a new attribute for lists (analogous to > expanse or width or other format hints) or as a conventional value for > outputclass=. > > It's too late for DITA 1.2 but I'm also finding that it would be really > handy to have a base type underlying all the lists (e.g., topic/list) > that would make it easy to implement a check for whether an element is > or is not a list. > > Cheers, > > Eliot > -- > Eliot Kimber > Senior Solutions Architect > "Bringing Strategy, Content, and Technology Together" > Main: 610.631.6770 > www.reallysi.com > www.rsuitecms.com > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]