Remove description root property, and rename specification_version and specification_source

[antpb]

…tion-version and specification-source for consistency with other props

Pull Request

What changed?

This removes the description field from root as it should be in sections. Also this renames the - separated field names to _

Why did it change?

Validation was breaking with proper json. This now makes it pass in my tool that uses the schema changes in this PR.

CERTIFICATION

By opening this pull request, I do agree to abide by
the CODE OF CONDUCT and be bound by the terms
of the Contribution Guidelines in effect on the date and time
of my contribution as proven by the
revision information in GitHub. I also agree that any previous contributions shall be deemed subject to the terms of the
version in effect on the date and time of this pull request, or any future revisions for pull requests I may submit.
Further, I certify that this work is my own, is original, does not violate the intellectual property of any other person
or entity, and I am not violating any license agreements or contracts I have with any person or entity. Finally, I agree
that this code may be licensed under any license deemed appropraite by AspirePress, including but not
limited to open source, closed source, proprietary or custom licenses, and that such license terms neither violate my
rights or my copyright to this code.

[yosefeliezrie]

@antpb

1. isn't the "description" field - a required field for the current WordPress.org repo? If it is, we should keep it.
2. I don't know how this would work, or to what extent the validation tool is checking things, but would it be possible to have your JSON validation tool be included as part of a GitHub actions check when pushing to the repo? I am unsure if it is worth the work, but since you already built this, it would ensure we have a valid spec each time and perhaps we could use it to validate the JSON of plugins to our spec as part of the plugin check process.

[antpb]

@yosefeliezrie thanks! Yeah. That's a big reason I left this PR open, I wondered if the duplicate description was intentional in the base spec. I think then this highlights we need to define the purpose of the sections object as being relative to the rendering of a plugin page. I'll update this PR to define that better,

On the validation, that's exactly what the screenshot is showing! :D
This is the final step before a user publishes to https://pluginpublisher.com

There's a tools directory in this repo that utilizes these schema docs to validate an input json matches expected fields and data types. I'll maintain these going forward as was well as this public cloudflare worker

curl -X POST \
https://calm-fog-c257.sxpdigital.workers.dev/validate -H 'Content-Type: application/json' -d '{"name": "XR Publisher", "slug": "xr-publisher", "version": "2.0-alpha", "author": "<a href=\"https://antpb.com\">antpb</a>", "requires": "5.0", "tested": "6.7", "requires_php": "7.2", "last_updated": "2024-10-09 12:00pm GMT", "added": "2024-10-09", "short_description": "A WordPress plugin for drag and drop 3D content creation compatible with most XR devices.", "description": "A WordPress plugin for publishing XR content with support for WebXR and popular glTF Extensions.", "download_link": "https://updater.sxp.digital/xr-publisher.zip", "spec_meta": {"specification-version": "1.0", "specification-source": "aspiprepress"}}'

This endpoint proves that folks can make validators based on the schema to do things like GitHub actions against it. All they need to do going forward is keep their references to the schema up to date. In my case I store the schema json files as KV stores in the cloudflare worker