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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]