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 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>...
DITA and XML Consultant, Learning by Wrote
Co-Chair, OASIS DITA Technical Committee
"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> 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.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




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