> Sure, in that case you can use the <keyword> element or use the audience > attribute. However, for my taste, it creates two distinct sets of > metadata: one from DocBook and the other from the vocabulary (in my > case, schema.org).
Yes. I considered that. I imagine you could go the other way and make
everything RDFa or Dublin Core or something. But then you’d have a very
non-DocBook DocBook document.
My (personal) inclination would still be to use the DocBook-native
metadata features where possible. But I can see how you might want to
use RDFa more consistently.
> Yes, the information should appear in the HTML source. If I'm not
> mistaken, RDFa Lite is currently not supported for the XSLT 1.0
> stylehsheets. This would need a customization layer (which I already
> have).
I’m pretty sure they’re supported by the xslTNG stylesheets.
>> It’s perhaps geared a little too strongly towards the HTML
>> style of meta element. It could probably be relaxed a
>> little bit, so that name was optional for example, to make
> it fit this use case a little better.
>
> If I read the TDG correctly, "name" is a required attribute, right?
> Wouldn't that make this attribute somehow unnecessary in the light of
> RDFa Lite?
That’s what I meant by “could probably be relaxed a little bit.”
> Not sure if the content model should be adapted. Something like a
> "HTML-like" <meta> element with name and a "RDFa Lite"-like <meta> with
> all other RDFa attributes. Would that make sense?
The RDFa attributes are already global, I think all that needs to be
changed is that the ‘name’ attribute should be optional.
Be seeing you,
norm
--
Norman Tovey-Walsh <n...@nwalsh.com>
https://nwalsh.com/
> The important thing in science is not so much to obtain new facts as to
> discover new ways of thinking about them.--William Bragg
signature.asc
Description: PGP signature
