Several fairly minor editorial changes#80
Conversation
Add whitespace surrounding attribute assignment required for well-formed XML for example in section 5.1.
The pictorial description of the DATA element in Section 7.1 has a trailing "<INFO>..." at the end, after the closing </DATA> tag. I don't think this is right; all of the other such boxes contain only a single element. Moreover, an <INFO> entry appears after the <DATA> entry in the TABLE box, so it really doesn't seem to be necessary here. This line seems to have got added between VOTable 1.1 and 1.2, when the position of the INFO element was revised, but I don't see any good reason for it, so it's just removed at this commit.
The location of the schema file is updated from http://www.ivoa.net/xml/VOTable/votable-1.5.xsd to http://www.ivoa.net/xml/VOTable/votable-1.6.xsd in a couple of places (doesn't exist yet, but it will on publication). I also changed the VOTABLE version attribute from 1.5 to 1.6 in the first example VOTable in the document.
Given that the first byte is asserted to start with the first bit, surely the second byte starts with the ninth not the eighth bit? But please somebody check I'm right here. This was probably my counting error in the first place.
The final VALUES example in section 4.7 as written was illegal, since the PARAM element had no values attribute. Changing the element to a FIELD fixes this. Probably the intention was to make clear that VALUES can be used with PARAM as well as with FIELD. This intention could be recovered, but it would be necessary to insert a value attribute (presumably either containing a circle triple or empty) into the example in that case for validity.
The second example of the GROUP element in section 4.9 uses the
value "Flux" for the name attribute both of one of the FIELDs
and of the GROUP that references that field.
This contradicts the advice from section 3.2:
"It is however recommended, as a good practice, to assign unique
names within a TABLE element. This recommendation means that,
between a <TABLE> and its corresponding closing </TABLE> tag,
name attributes of FIELD, PARAM and optional GROUP elements
should be all different."
So I've renamed the group as "FluxGroup".
Arguably it would be a good idea to rename the GROUP in the previous
example from Velocity to VelocityGroup as well? But since that
example lacks any context, there's no namespace clash there.
Some of the \hline macros in VOTable.attr.tex which draws the
Attribute Summary in section 7.3 were written \hline{}.
This achieved, as far as I can tell, no good purpose, but resulted
in very slightly annoying whitespace before the first attribute name
in each box in the PDF rendering. s/hline/hline{}/g fixes it.
msdemlei
left a comment
msdemlei
left a comment
There was a problem hiding this comment.
While I can't in every case say exactly why the change improves matters, it all looks rather reasonable except for the trailing blanks. Let's go.
| \begin{verbatim} | ||
| <TABLE> | ||
| <FIELD name="aString" datatype="char" arraysize="10"/> | ||
| <FIELD name="aString" datatype="char" arraysize="10"/> |
There was a problem hiding this comment.
Please don't have trailing blanks in ivoatex documents.
There was a problem hiding this comment.
I don't see trailing blanks on those lines in the sense of whitespace at the end of a line.
The whitespace you're highlighting is inside an XML tag but not at the end of the line - is that what you mean? It's there because I'm following the character alignment that was there before (so the arraysize attributes are aligned), I just shunted everything over by one space. I'm not particularly attached to that so don't mind changing it to more normal XML tag spacing, but I'm not sure if I'm missing the point here.
msdemlei
left a comment
msdemlei
left a comment
There was a problem hiding this comment.
My last review was confused by reflow of lines in the browser. Apologies for having been thick.
|
Ah well you stimulated me to go looking for some real trailing whitespace and I found a couple of instances, so no bad thing. |
2 participants
Mixed bag of edits. They are not all logically connected, but I couldn't face 8 separate PRs.
At least one or two of these might be argued about so some scrutiny would be welcome. See commit messages for detailed justification in each case.