Making extension texts more uniform

[SunSerega]

I finally made some time to deal with #361 and such. But it needs some preparations.
As i said in #361 - it makes sense to first un-consider irrelevant extension. And obviously, i want to at least somewhat automate this process.
I already have programs to data-scrap most of relevant here info, but they work in a lot of hacky ways, with a lot of ways for me to miss something. I think i can redo it in a lot better way.

The main problem with data-scraping texts of extensions is that they aren't uniform. For instance:

1. In the end of EXT_packed_depth_stencil.txt:

   Revision History
   
   #12 September 26, 2005
       - Fix copy/paste error in the example.
   

   In most of places tabulation is kept in a way, where only section headers have 0 indentation before them. And so simplest algorithm would see #12 September 26, 2005 as name of new section. And it's not as easy as treating lines starting from # as non-section-starter's, i'ev only shown simplest example here.

2. You can say "then make whitelist-like rules, what can be considered section name". But they aren't uniform too. For some reason, everyone loves calling New Procedures and Functions their own way. There is even random line break in the middle of it's name in one of extensions - SGIX_slim.txt.

---

So, i can either make pre-parsing text transformation rules, or go through extension texts a few times with small programs, making 1 thing more uniform at a time (for instance first fix identation's, then separately make section names more uniform).
Second option only makes sense if i'm also going to submit fixed version of extension files to this repository.

TL;DR: Does pull have a chance of being merged, if it wouldn't affect the meaning of extension texts, but would make them look better?
And if yes - are there things i absolutely should not touch?

[pdaniell-nv]

@SunSerega the working group is potentially open to this change, but we would like to see an example or two to make sure we agree on what the change will look like. Thanks.

[Perksey]

Yeah it'd be cool, but if you're preparing to go down the line of parsing the extension specs then that's a slippery slope at best! But yeah, fixing some little structural issues would be neat, but if you could formalize the proposal similar to #335 then the working group can have a better grasp on what to review.

[oddhack]

IIRC somebody did something along these lines in a Google Summer of Code project a long time ago. It's very difficult to parse the arbitrary content in these documents though, and getting signoff from the many EXT and vendor extension owners effectively impossible.

[oddhack]

In particular reformatting the documents stands a significant chance of screwing up things that are intended to be tables, equations, diagrams in ASCII text.

[Perksey]

and getting signoff from the many EXT and vendor extension owners effectively impossible.

Oh boy I didn't even think of that.

[SunSerega]

and getting signoff

Well, that's part of the main question for which i made this issue.

I have backup ideas too... But did i understand right that NVidia extensions wouldn't need signoff's of every author, since @pdaniell-nv's comment?

[Perksey]

Each extension has a main contact displayed at the top of the file who in an ideal world should sign-off significant restructurings.

[pdaniell-nv]

I'm sure a lot of those main contacts are no longer relevant, especially for the very old extensions. Sadly there is no easy way to do this. Depending on what the changes look like the working group might be able to sign off for all of them. We would need to see some examples and discuss.

[SunSerega]

Thanks for feedback!

I got distracted with a few things since asking this question. And yeah, i understand i should've posted example changes to at least a few files before asking it.

Anyway, i'll prioritize this when i have time again, maybe doing things in some different way.
If this issue is in the way - it can be closed it for now, i'll link it when making draft anyway...