OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]