OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: Re: [docbook] No nested <meta> elements?


Hi Norm,


On 18.03.22 12:40, Norm Tovey-Walsh wrote:
>> It isn't allowed to add a <meta> element inside another <meta>, right? Is there
>> a specific reason for this? What would your take on allowing nested <meta>s?
>
> The new meta element isnât allowed in very many places. Itâs a child of
> info (and a few bibliographic elements), to provide generic metadata.

Yes, that was my understanding too. I don't object that <meta> is only allowed
as child of info. :)


> Having a generic element means users donât have to resort to tag abuse
> of, for example, bibliomisc, as I have so often done.

Absolutely. I also don't object to <meta> itself.


> [...]
> What would the use case be for nested meta elements?

Well, the child elements of <meta> carries a lot of semantic meaning. In some
cases it's fine, in other cases it's not.

For example, we would like to express that a topic belongs to specific products
and specific versions. One example (probably not the best) could look like this:

  <meta name="products">
     <meta name="HA" content="10SP1,10SP2,10SP3"
         >My HA product</meta>
     <meta name="Server" content="10SP1,10SP2"
         >My server product</meta>
  </meta>

If I want to add additional levels, like a short and long name, I could do that
too:

  <meta name="products">
    <meta name="abcd" content="10SP1,10SP2,10SP3">
      <meta name="short" content="ABCD"/>
      <meta name="long"  content="The ABCD long product name"/>
    </meta>
  </meta>

As <meta> allows to add almost anything I want into the name and content
attributes, it doesn't give us lot of restrictions. Additionally, it's short
and easy to type.

Of course, this could also expressed with <productname> and probably <phrase>,
but that looks kind of wrong to me. Sometimes you don't have a matching DocBook
element that fits to your metadata and you would abuse it. With <meta>, you
don't have this issue.

Another issue could arise, if someone customizes DocBook (as we do). The
customization layer could potentially remove productname or any other inline
element. This would seriously limit the selection. Allowing nested <meta>s
would reduce this risk.

As a conclusion, I would prefer a more general, shorter, and directer approach
to avoid abusing other DocBook elements. Thus, the question about nesting <meta>s.

Does that make sense?


--
GruÃ/Regards
  Thomas Schraitle


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