[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?
I have to mention that every time I talk about it to an audience. I would hope we can address this in DITA 2. Cheers, E. On 3/1/12 2:29 AM, "Noz Urbina" <noz.urbina@mekon.com> wrote: > I'd just like to make sure I don't forget to toss in here that calling a tag > meant for metadata 'data' is extremely confusing from the outset. > > I've been misunderstanding it since it appeared, even having read the > specification. Is it a consideration to clear up the semantic in DITA 2? > > -----Original Message----- > From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf > Of Eliot Kimber > Sent: 29 February 2012 20:22 > To: Nitchie, Chris; Don Day (LbyW); dita > 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 > > > --------------------------------------------------------------------- > 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]