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: Improve content model of <othermeta>


Hello,

 

I’d like to follow up on the discussion at the 18 January 2022 meeting that I was unable to attend due to illness. As you all know, we made a concerted effort in the DITA 1.2 timeframe to remove all attributes containing translatable content. Somehow a few fell through the cracks and remain to this day… The <othermeta> element is one of them. I would like to propose that we address this gap in DITA 2.0. I am willing to drive the stage 2 and 3 proposals for this, if the TC agrees we should move forward with my proposal.

 

My proposal is to modify the content model of <othermeta> so that its attributes don’t contain translatable content. My initial thoughts are as follows:

 

The current content model for <othermeta> is empty, with all content being applied to the attributes @name, @content, and @translate-content.

 

My suggestion is to keep the @name attribute as-is and inherit the standard @translate attribute instead of the current unique @translate-content attribute. The translate attribute works as usual. Then, replace the current @content attribute with PCDATA. If for some technical reason we can’t, or prefer not to, have only PCDATA in an element, we could allow <ph>. Allowing <ph> may complicate things and would require more thought to review what would be included in the content model. I suppose we could constrain any undesirable inline elements out.

 

With this new content model, translatable content is in the <othermeta> element as content, not in its attribute value. I am also open to having one child element named <content> if the TC wants an element that clearly replaces the content attribute. Then <content> can contain PCDATA or whatever we end up with. I’m just not mad about elements containing one element, it seems like unnecessary overcomplication of the content model to me.

 

In any case, this is my proposed stage 1 proposal.

 

Please share your thoughts, concerns, etc.

 

Thanks,

Gershon

 



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