[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?
That constraint would satisfy my requirements. I agree that allowing it between list items would not be useful and would probably encourage abuse. Cheers, E. On 2/29/12 1:19 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote: > I worry about interspersing <data> between list items, but if <data> > elements always come first - "(data*,li*)", not "(data|li)*" - I think > it makes sense. > > Chris > > -----Original Message----- > From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On > Behalf Of Eliot Kimber > Sent: Wednesday, February 29, 2012 1:58 PM > To: Don Day (LbyW); dita > 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 > > > --------------------------------------------------------------------- > 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]