On 18 August 2014 15:45, Joaquin M Lopez Munoz wrote:

In my particular case, My name appears with full diacritics and stuff in the authors section:

"authors": [ "Joaqu\u00edn M L\u00f3pez Mu\u00f1oz" ]

Sorry about that. You can actually use UTF-8, there's no need to escape unicode characters, it's just that the json generator does it by default. I've fixed some of the pull requests.

but not in the maintainers section

"maintainers": [ "Joaquin M Lopez Munoz " ]

Is it OK to also use Unicode in the latter?

I took that data from the maintainers.txt file, and the idea is to be able to generate it automatically in the future. So I think it depends on whether we'll allow unicode in that file. I think it's probably okay.

On 18 August 2014 16:32, Robert Ramey wrote:

I'm curious about this metadata idea.

Maybe there has been a discussion about it and I didn't see it.

It's been discussed on several occasions, often in passing. When I first started adding the metadata to libraries, I posted about it: http://lists.boost.org/Archives/boost/2014/02/211799.php

But in any case I have a couple of questions:

a) what is the immediate intended purpose and benefit?

The immediate benefit is that it lets people update their library details without modifying the website.

b) what are some possible future intended purposes and benefits?

Creates a single location for the data, which is currently duplicated in several different places, and is often inconsistent. We might also add more data, such as expected failures.

c) why was json chosen rather than some xml schema. The reason I ask this is that your documentation build system is based on xml transforms.

My documentation build system? If it was up to me, the documentation build wouldn't have been based on xsl.

It seems to me that (not having answers to the a and b above) that a more natural choice for something like would be some xml schema.

It was originally in xml, because that's what the website uses. But someone asked for json, and that seemed fine to me as I think people find it easier to read and write.

On 18 August 2014 17:05, Glen Fernandes wrote:

On Mon, Aug 18, 2014, Daniel James wrote:

...

Creates a single location for the data, which is currently duplicated in several different places, and is often inconsistent. We might also add more data, such as expected failures.

I wonder if the root index.html in every library could be generated from information specified in meta/libraries.json also - instead of each library providing a handwritten version with not much more than a redirect.

Not with the current contents of libraries.json, as the root index.html file is typically considered the location of the documentation, since it's typically more permanent, predictable and memorable than the actual location. For most libraries, you can go to something like 'http://www.boost.org/libs/smart_ptr' and end up in the right place, even if the documentation files are moved to a new location within the module.

On 19 August 2014 00:50, Niall Douglas wrote:

On 18 Aug 2014 at 15:23, Daniel James wrote:

...

I just created about 100 pull requests to add library metadata to modules that don't already have it. Apart from them all containing the same typo, I think it went okay. I forgot to mention that the file format is documented at:

http://www.boost.org/development/library_metadata.html

I'll spend a bit of time improving that soon, so let me know if there's anything missing.

Can you add the following fields please:

I meant missing from the documentation. I'm not volunteering to track every possible piece of data available. Most of your requests don't fit with the intent of this file, and belong elsewhere. It'd probably be a bad idea for me to design the necessary data structures anyway, as I'm not involved in any of the uses and would probably get them wrong.

On 19 August 2014 12:43, Niall Douglas wrote:

On 19 Aug 2014 at 7:12, Daniel James wrote:

...

...

...

I'll spend a bit of time improving that soon, so let me know if there's anything missing.

Can you add the following fields please:

I meant missing from the documentation. I'm not volunteering to track every possible piece of data available. Most of your requests don't fit with the intent of this file, and belong elsewhere. It'd probably be a bad idea for me to design the necessary data structures anyway, as I'm not involved in any of the uses and would probably get them wrong.

Would you be okay if people added extra optional fields i.e. would your parser skip them without problem? I think between myself and Robert we can add some good optional metadata extensions.

It's possible to add extra fields, but I'd rather keep this file fairly small and static. It shouldn't take a lot of work to write it, and shouldn't need to be updated too often. It's also quite likely that it will be replaced by something else in the future, especially if we ever have a package management system. It's not intended to be a permanent solution.

If that isn't possible for you, any objection to an extra json file appearing in meta/*?

Not really, and even if I did, I don't have any special authority here. I'd suggest making a proposal in a new thread. My concern would be how much work this would require from maintainers. Currently the metadata file is optional, and fairly simple. Btw. if you're doing something with test data, it might be worth looking at 'status/explicit-failures-markup.xml' and seeing if you can incorporate that in some manner.