Closed dericed closed 4 years ago
I am not sure if adding more URLs is a good idea, these will especially in a official slowly changing document like a RFC possibly become dead.
In my opinion the reference makes the life easier for people looking for the source, and archive.org has a copy. If the link is broken in the future, it does not hurt more than if there is no link. So I am in favor of adding the URL.
Hi @michaelni, note that without this PR the make process will break starting with mmark 2.2.8. The range encoder reference uses a seriesInfo element with a @name
attribute but no @value
attribute. According to rfc7749 the @value
attribute is mandatory. Since starting with mmark 2.2.8 this seriesInfo element will be passed along, then xml2rfc
will give an error:
xml2rfc --html --v3 "draft-ietf-cellar-ffv1-15.xml" -o "draft-ietf-cellar-ffv1-15.html"
draft-ietf-cellar-ffv1-15.xml(1904): Error: Element seriesInfo failed to validate attributes, at /rfc/back/references[2]/reference[10]/seriesInfo
draft-ietf-cellar-ffv1-15.xml(3): Error: Invalid document before running preptool.
Unable to complete processing draft-ietf-cellar-ffv1-15.xml
make: *** [draft-ietf-cellar-ffv1-15.html] Error 1
nudge about this PR, looks like it is the only one blocking before being able to request a new AD review.
ive looked at the link again, this is a commercial site, (which atm doesnt work) but google lists for it "Compression Consulting gives technical expert advice for your specific data compression problem. A first inquiry is free." This link is rejected. The site seems an inappropriate choice as reference
about mmark, ive updated it and with just that the first commit build fails:
draft-ietf-cellar-ffv1-16.xml(1922): Error: Element seriesInfo failed to validate attributes, at /rfc/back/references[2]/reference[8]/seriesInfo
draft-ietf-cellar-ffv1-16.xml(3): Error: Invalid document before running preptool.
Unable to complete processing draft-ietf-cellar-ffv1-16.xml
Makefile:24: recipe for target 'draft-ietf-cellar-ffv1-16.html' failed
@michaelni the website is working on my side (and archive.org has it too) and it links to a PDF: http://www.compressconsult.com/rangecoder/rngcod.pdf.gz Would a link to the PDF acceptable? It wouldn't let spec readers get a source (on the website) code though. (in any case, IMO a link to a commercial site is still better than no link)
Hi @michaelni, that specific error message was addressed for me by updated to mmark 2.2.8 as https://github.com/mmarkdown/mmark/commit/13c52eb7217836a78bf0a159b2e76ba441b34984 fixes this issue of missing seriesInfo in references. Can you run mmark -version
to verify the right version.
@michaelni the website is working on my side (and archive.org has it too) and it links to a PDF: http://www.compressconsult.com/rangecoder/rngcod.pdf.gz Would a link to the PDF acceptable? It wouldn't let spec readers get a source (on the website) code though. (in any case, IMO a link to a commercial site is still better than no link)
And when the site is reorganized the link would then redirect to the front page of that consulting thing. Its not appropriate for a RFC to contain a link to this IMO
Hi @michaelni, that specific error message was addressed for me by updated to mmark 2.2.8 as mmarkdown/mmark@13c52eb fixes this issue of missing seriesInfo in references. Can you run
mmark -version
to verify the right version.
i did install 2.2.8 before trying so yes it shows "2.2.8". That said i think the build system needs some more friendly debug support, like a log file or something that contains more info so no back and forth questions are needed, that said, the thing should check versions and fail with clear error messages
@michaelni, in regards to a build system, what do you think of using the same approach that @robUx4 used in the ebml and matroska repositories? There's a bootstrap file to facilitate ensuring dependencies are present and meet a minimum version requirement.
@dericed , i think a script identifying missing and outdated packages is a good idea. I also think providing commands to the admin of the computer on how to install new enough packages / versions of the tools makes sense. But the actual execution of the commands to install new tools / packages should be up to the admin. I do not believe in black box scripts which directly install tools. ...
For python scripts they are installed locally to the user using pip. For mmark (in go) the Linux/mac binary is downloaded from the github repo and decompressed in the local folder. The rest there's just a lost instructing the user to install
Updated to master and removed to requirement for mmark 2.2.8; however, note that part of the references output will be different in mmark versions before 2.2.8 since those neglect to present the seriesInfo/@value attribute as part of the citation.
Ive applied the 2.2.8 requirement but the link to a random .com site gives me a stomach ache. Can we please refer to some normal academic / primary litrature if we need a reference.
@michaelni To my knowledge, the mentioned report by G.N.N. Martin has not been published elsewhere. At least, I could not find it… (I used it for a class in codec programming back in 2015.) However, the main content has been integrated into some of the following articles he published together with other authors mainly in the early 1980s, but I could not suggest one as a full replacement. (I still use these from time to time for my teachings on IT history.)
@dericed mmark 2.2.9 has been released in the meantime ;-)
Iam not sure if adding more URLs is a good idea, these will especially in a official slowly changing document like a RFC possibly become dead. About the mmark bump, like always i see requiring the most recent software suboptimal