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



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