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?


>People should not need to understand what's going on if they don't see tags.
It should work like Word.

I'm in favour of that generally.  Not necessarily Word, but 'as you'd expect to work'.   The rest of this is not so much for you as it seems we agree but more detail on the issue....

We have two contradictory aims:
- make the structure reusable and consistent
- make the thing usable

The current structures don't allow for stem sentences at all on lists, so the only way to do this is wrap the whole thing in a para:

<p>CDATA:stem sentence
<ul><li></li><li></li></ul>
Maybe some more CDATA</p>

This makes a nice reusable discrete <p>, but screws up translation processes and is hard to represent in a friendly when as compared to:

<p>CDATA: Totally unrelated
<ul><li></li><li></li></ul>
Maybe some more totally unrelated CDATA</p>

And can lead (easily in a tagless world) to:

<p>CDATA: Totally unrelated
<ul><li></li><li></li></ul>
Maybe some more totally unrelated CDATA
<ul><li></li><li></li></ul>
Maybe some more totally unrelated CDATA
<ul><li></li><li></li></ul>
Maybe some more totally unrelated CDATA</p>

Which is ugly, ugly DITA.

The cleaner approach structurally is:

<p>CDATA:stem sentence</p>
<ul><li></li><li></li></ul>
<p>Maybe some more CDATA</p>

But then what should be a single unit is not anymore.  There's pros and cons both ways.  I think that with conref range, the latter becomes is reusable, and I would chuck out the former completely.

Noz

-----Original Message-----
From: Laurens van den Oever [mailto:lvdoever@sdl.com]
Sent: 01 March 2012 16:31
To: Noz Urbina; Rob Hanna; Eliot Kimber; Nitchie, Chris; Don Day (LbyW); dita; Mark Poston
Subject: RE: [dita] Reasonable to allow <data> in ol/ul/sl/dl?

And I second that Noz.

In fact I see a need to make that decision everywhere where CDATA and <p> are
allowed on the same level.

Note that <ul>/<ol>/<dl> in <p>s is illegal in HTML and may cause unexpected
results when you choose to output the elements one on one to the HTML
equivalents.

I am in favor of <p>s in <li>s though because:
> - makes it almost impossible to understand what's going on in a tagless
authoring view
People should not need to understand what's going on if they don't see tags.
It should work like Word.
Word has <p>s in <li>s and so should DITA.

Laurens

-----Original Message-----
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf
Of Noz Urbina
Sent: donderdag 1 maart 2012 16:03
To: Rob Hanna; Eliot Kimber; Nitchie, Chris; Don Day (LbyW); dita; Mark
Poston
Subject: RE: [dita] Reasonable to allow <data> in ol/ul/sl/dl?

I second that strongly.

I also find the need to make a structural decision of when to nest <p>s in
<li>s or <ul>/<ol>/<dl> in <p>s is:

- unacceptably complex for users
- makes it almost impossible to understand what's going on in a tagless
authoring view
- creates havoc in translations if you do opt to nest block-level items of
lists inside <p>s
- because of the above can end up making it harder to keep structural
consistency across a content set

Noz

-----Original Message-----
From: Rob Hanna [mailto:rob.hanna@Innovatia.net]
Sent: 01 March 2012 15:56
To: Eliot Kimber; Noz Urbina; Nitchie, Chris; Don Day (LbyW); dita
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


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