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" <> 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: [mailto:] 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" <> 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: [mailto:] 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)" <>
>> 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:>
>>>
>>> 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" <>
>>>> <mailto:> 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:
>>>>> For additional commands, e-mail:
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>>>
>>>>
>>>>
>>>
>>
>> --
>> 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:
>> For additional commands, e-mail:
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>>
>
> --
> 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:
> For additional commands, e-mail:
>
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com
