[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Reasonable to allow <data> in ol/ul/sl/dl?
Abuse of <data> for non-metadata is definitely a concern, but that's also true for pretty much any very-general element in DITA, so I'm not sure <data> is that special of a case, but we do need to take that concern into account. One of the general challenges we face is that the inability to add arbitrary attributes requires the use of <data> or PIs to capture the equivalent in most cases. For most such cases <data> is already allowed where it needs to be, but within lists seems to be a case that was possibly overlooked. Certainly the sort of Publishing-focuses legacy conversion cases as reflected in the DITA Users post are outside of the original scope of DITA requirements. There's also the general moving-to-DITA challenge of replacing common XML practice of using lots of attributes with the DITA equivalent, which usually means <data>. In a Publishing context, lists are a particular challenge because authors often have the freedom to do whatever they want and they usually do. Cheers, E. On 2/29/12 12:45 PM, "Don Day (LbyW)" <donday@learningbywrote.com> wrote: > I saw that request in dita-users, Eliot. I suspect that if <data> were to > be allowed everywhere with only processor-specific rendering allowed, we'd > have effectively moved the intent of PIs out of metalanguage and into the > content model itself. I don't think this is necessarily wrong as long as the > data element never produces literal output. But things get interesting if > different tools can operate on the same data (say, Mark's financial data in > its specialization falls through to an undiscerning data processor, say, an > inline revision alternative to PIs that happens to enable rendering). So I'm > concerned about the general potential for PCDATA to be rendered into > element-only spaces in a strictly-validated result tree. Of course, this could > happen with PIs as well in the same context. I can see someone thinking they > could specialize between-element data to enable this (with their own override > processor to do the expose): <steps><data>My own stem > sentence:</data><step>... > > > > Don R. Day <mailto:donday@learningbywrote.com> > > DITA and XML Consultant, Learning by Wrote <http://learningbywrote.com/> > Co-Chair, OASIS DITA Technical Committee > <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita> > > > "Where is the wisdom we have lost in knowledge? > > Where is the knowledge we have lost in information?" > > --T.S. Eliot > > > > > On 2/29/2012 11:52 AM, Mark Poston wrote: >> >> Hi >> >> I am working on a project now where a specialised form of data will be >> required. >> >> The specialised tags need to represent financial data such as exchange rates. >> I was thinking <data> was the most appropriate tag for this to be specialised >> from. >> >> Therefore allowing <data> anywhere would be necessary. >> >> Regards >> >> Mark Poston >> >> Sent from my iPhone >> >> On 29 Feb 2012, at 15:45, "Eliot Kimber" <ekimber@reallysi.com> >> <mailto:ekimber@reallysi.com> wrote: >> >> >>> >>> Currently none of the list elements allow <data> as direct children. >>> >>> I'm thinking maybe they should. >>> >>> The immediate use case is capturing metadata that reflects details of a list >>> from legacy content, such as the numbering or bullet style details and the >>> initial number. I can think of other list-specific metadata that might be >>> useful, such as subject classification or whatever. >>> >>> I think that we should be following a general principle of allowing <data> >>> anywhere that it isn't clearly inappropriate, and I can't think of any >>> obvious reason why it would be inappropriate in a list. >>> >>> Is there some history as to why <data> is not allowed as direct list >>> children, other than "we never thought about it"? >>> >>> Cheers, >>> >>> E. >>> >>> >>> -- >>> Eliot Kimber >>> Senior Solutions Architect >>> "Bringing Strategy, Content, and Technology Together" >>> Main: 512.554.9368 >>> www.reallysi.com <http://www.reallysi.com> >>> www.rsuitecms.com <http://www.rsuitecms.com> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: dita-help@lists.oasis-open.org >> >> >> > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]