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 would specialize <data> as needed to capture the financial data. The
specialization would then carry the semantic of "embedded financial data".

I will note that I have never though of <data> in the sense of "data
primarily intended for consumption by machines" and don't know that I've
ever had that sort of use case.

I have always used it in the sense of "metadata about the content" and
primarily use it for classification, but also to capture other details, such
as literal numbers captured during legacy conversion, or used where one
would otherwise use attributes in normal XML practice.

Which is not to say that the two uses are inconsistent with each other, just
that they are different and I've only ever considered  one of them.

Note that I'm not suggesting we need a replacement for processing
instructions--I think there's a place for them them and no particular need
to replace them with a DITA-defined markup convention.

Cheers,

E.


On 3/1/12 10:05 AM, "Michael Boses" <mboses@contelligence.org> wrote:

> My usage of data has always been to carry a machine readable payload but it
> sounds like we are talking about four different requirements:
>  
> ·         a replacement for arbitrary attributes
> 
> ·         a replacement for processing instructions
> 
> ·         a more flexible structure for metadata than arbitrary attributes
> would provide if they existed
> 
> ·         a container for machine readable data
> 
>  
> Is this too much to ask from one element? Elliot, if one of your publishing
> scenarios also required the incorporation of financial data as Mark mentioned,
> is there an additional requirement to clarify the structure semantically or
> would you simply identify the usage in the content of the <data> container
> itself?
>  
> Michael
>  
>  
>  
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf
> Of Michael Priestley
> Sent: Thursday, March 01, 2012 9:42 AM
> To: Eliot Kimber
> Cc: Nitchie, Chris; dita; Don Day (LbyW); Noz Urbina
> Subject: Re: [dita] Reasonable to allow <data> in ol/ul/sl/dl?
>  
> I thought it was for any kind of content not intended for human consumption,
> at least by default.
> 
> For example if a software procedure could be performed by either a machine or
> human agent, <data> might be used to hold extra information for the machine
> agent. 
> 
> Another example would be messages documentation, where the same source
> document feeds both the appearance of the message in the software (with
> machine-oriented data for determining when and how the message is triggered,
> etc.) and the documentation of the message in an infocenter.
> 
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
> 
> 
> 
> From:        Eliot Kimber <ekimber@reallysi.com>
> To:        Noz Urbina <noz.urbina@mekon.com>, "Nitchie, Chris"
> <cnitchie@ptc.com>, "Don Day (LbyW)" <donday@learningbywrote.com>, dita
> <dita@lists.oasis-open.org>,
> Date:        03/01/2012 09:24 AM
> Subject:        Re: [dita] Reasonable to allow <data> in ol/ul/sl/dl?
> Sent by:        <dita@lists.oasis-open.org>
> 
> 
> 
> 
> 
> 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
>> <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
>>> <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
>>>> <mailto:donday@learningbywrote.com> >
>>>> 
>>>>  DITA and XML Consultant, Learning by Wrote
>>> <http://learningbywrote.com/ <http://learningbywrote.com/> >
>>>>  Co-Chair, OASIS DITA Technical Committee
>>>> <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
>>>> <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 <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 <www.reallysi.com>  <http://www.reallysi.com
>>>>>> <http://www.reallysi.com/> >
>>>>>> www.rsuitecms.com <www.rsuitecms.com>  <http://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.reallysi.com>
>>> www.rsuitecms.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.reallysi.com>
>> www.rsuitecms.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]