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: Reasoning for not cascading <othermeta> metadata


John, I’ll add your e-mails to the agenda for our next DITA TC call.

 

However, I cannot imagine that we would make any changes to the standard. The <othermeta> element has never cascaded. Changing it to be an element that cascaded – Why would we want to do this? It might have serious impacts to many implementations.

 

What is it that you are trying to do? I bet there are other changes that you can make to your DITA source and DITA-OT processing.

 

Best,

Kris

 

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com

Skype: kriseberlein; voice: +1 (919) 622-1501

 

From: Kirkilis, John (Nokia - US/Austin) <john.kirkilis@nokia.com>
Sent: Wednesday, November 16, 2022 9:24 PM
To: Kristen James Eberlein <kris@eberleinconsulting.com>; dita-comment@lists.oasis-open.org
Subject: Re: Reasoning for not cascading <othermeta> metadata

 

Whoops. Auto-correct error.

 

What I meant to ask is why does one "other" cascade and the other one does not (<othermeta> vs @otherprops), regardless of whether one is an element and one is a conditional attribute.

 

They are both meant to handle use cases where the built-in choices are insufficient.

 

I asked Jarno how we, Nokia, would extend the processing to do this ourselves in DITA-OT, and he highly recommended not doing it. I don't recall his specific reason however, but could find out. It might have required that we fork the OT project, which would be a very last resort.

 


From: Kirkilis, John (Nokia - US/Austin) <john.kirkilis@nokia.com>
Sent: Wednesday, November 16, 2022 8:35 PM
To: kris eberleinconsulting.com <kris@eberleinconsulting.com>; dita-comment@lists.oasis-open.org <dita-comment@lists.oasis-open.org>
Subject: Re: Reasoning for not cascading <othermeta> metadata

 

Following up after DITA-OT day. The conditional attribute “otherprops” cascades, so how does its use case differ ?


From: kris eberleinconsulting.com <kris@eberleinconsulting.com>
Sent: Sunday, October 2, 2022 8:18:20 PM
To: Kirkilis, John (Nokia - US/Austin) <john.kirkilis@nokia.com>; dita-comment@lists.oasis-open.org <dita-comment@lists.oasis-open.org>
Subject: RE: Reasoning for not cascading <othermeta> metadata

 

Hi, John.

 

<othermeta> is a general purpose element. There is no knowing what people might use it for, so it does not cascade.

 

You certainly can customize your processing so that specific values for <othermeta> will cascade …

 

Best,

Kris

 

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com

Skype: kriseberlein; voice: +1 (919) 622-1501

 

From: Kirkilis, John (Nokia - US/Austin) <john.kirkilis@nokia.com>
Sent: Saturday, October 1, 2022 9:27 AM
To: dita-comment@lists.oasis-open.org
Subject: [dita-comment] Reasoning for not cascading <othermeta> metadata

 

Hi Kris and company,

 

We’re building a new HTML5 HelpCenter in React that integrates with our products. For faceted search, metadata is essential.

 

The spec indicates in the cascade table that othermeta does not cascade as do the standard metadata elements.

 

I have two questions:

 

  1. Can you explain the reasoning for this exception so I can better understand the matter?
  2. How have you or others propagating <othermeta> metadata to child topicrefs?

 

Best Regards,

 

John



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