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 wouldn't push for titles on lists necessarily but I have a fairly strong desire to see the desc element. I feel it would go a long way to solving how we create stem sentences for lists. I know there are those in our community that abhor the idea of putting a list in a paragraph but for me that seems to be the only real option for creation of stem sentences. With the desc element, the stem could travel with the list itself without needing to nest it in a paragraph.

Rob Hanna
Senior Information Architect
Tel: +1 (506) 674-5660


-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Thursday, March 01, 2012 9:50 AM
To: Rob Hanna; Noz Urbina; Nitchie, Chris; Don Day (LbyW); dita
Subject: Re: [dita] Reasonable to allow <data> in ol/ul/sl/dl?

There is a general tension in DITA between titled things and not-titled
things and nestable titles and non-nestable titles.

The DITA architecture tries to carefully distinguish between titled things
that contribute to navigation (topics, figures, tables) and titled things
that do not (sections). In particular, DITA distinguishes titled things that
can nest (topics) from titled things that cannot (fig, table, section).

This distinction makes good sense in a tech-doc world and I think is an
appropriate discipline for writing in general.

In my work with Publishers and the challenge of capturing legacy content it
sometimes poses a problem, but to date not an insoluble one.

I think the legacy conversion challenge reflects a lack of appropriate
rhetorical analysis and discipline in the original, not a flaw in the DITA
architecture. It does meant that legacy conversion requires more thought to
determine if something that appears to be titled should be a figure, a
section, a topic, or something that is titled only through style (e.g., a
<div> as we've now defined that element).

I think it would be a violation of this architecture to allow lists to have
titles and descriptions.

Cheers,

Eliot


On 3/1/12 8:37 AM, "Rob Hanna" <rob.hanna@Innovatia.net> wrote:

> I was just having a very similar conversation with a colleague over coffee
> last night.
> 
> Both figure and table use the desc element to provide meta information about
> the object that can be rendered as a stem sentence in the content. This is a
> brilliant model that facilitates very good modularity and reuse.
> 
> Why can we not extend the desc element (and title element for that matter) to
> the list? The desc element supports data elements as well. This would provide
> for some semantic context for the data elements that describe the list.
> 
> (title?, desc?, li+)
> 
> Cheers,
> 
> Rob Hanna
> Senior Information Architect
> Tel: +1 (506) 674-5660
> 
> -----Original Message-----
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf
> Of Eliot Kimber
> Sent: Thursday, March 01, 2012 9:24 AM
> To: Noz Urbina; Nitchie, Chris; Don Day (LbyW); dita
> 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
> 
> 
> ---------------------------------------------------------------------
> 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]