You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently a number of separate annexes (J through P) in the specification, each describing a different extension. This information all overlaps with what is in section 3. Since this information is not part of the core, it could all be moved into a single annex.
The text was updated successfully, but these errors were encountered:
If this hasn't already been done, I'd like to ask that it not be applied. This is just churn for no real value - breaks references (e.g. in code samples), and does not make it easier for future implementers.
I understand your concern here but I don't think it will be a big deal. Section anchor names are automatically generated based on section titles so if entire sections are moved, the anchor names should remain the same.
Right now the bigger issue is that information regarding a specific extension is scattered around the document. Having to flip back and forth between Section 3 and an annex has proven painful. This will only get worse as new extensions are added, requiring more and more annexes (and forcing the annex IDs to change each time).
@bradh I'm sorry but it had to be done. Right now the information about a particular extension is spread across at least 4 different parts of the document. It is unreasonable to expect a reader to be able to find all of the relevant information.
This is pain for me too. I'm going to have to review every reference in the abstract test suite because they are hard-coded, not linked. I'm sure there are other parts to this that will bite me too.