Conversation
Allows to refer to the XSL from outside this github repo.
Now we have a nice display of the XEP number, yay!
The idea would be to integrate this in the XSF XEP XSLT. However, it doesn't work that well: - xinclude does not work in browser XSLT engines.
Syntax and indentation
This schema’s canonical URL is https://linkmauve.fr/ns/xmpp-doap but it is also hosted here for ease of contribution.
For each implemented XEP, this: * adds a column with the title of the XEP, * the XEP abstract is injected in the "title" attribute; * adds a column with the latest revision number, * the date of the latest revision is injected in the "title" attribute; * adds a "title" attribute to the implemented revision number with the publication date of that version; and * styles the implemented revision column according to whether the project implements a current or outdated revision. It does this by referencing the relevant XEP XMLs, not the abridged list found at https://xmpp.org/extensions/xeplist.xml as that one does not have full revision details (so we can extract the date of the *implemented*, as opposed to latest, revision) and it also makes matching marginally more awkward as the XEP numbers are given with a varying number of digits. Lastly, that relies on xeplist.xml being complete and up to date whereas taking the XEP references entered by the user relies on the *.html and *.xml versions being in the same path. One marginal advantage is that this doesn't break if the author announces support for private XMLs (which probably won't be in xmpp.org or in xeplist.xml). Note 1: Generation with xsltproc will probably not work: https://gitlab.gnome.org/GNOME/libxslt/-/issues/28 Use a better tool instead, such as Saxon (http://saxon.sourceforge.net/). Note 2: If the XEP XMLs were served with `Access-Control-Allow-Origin: *`, the XML could be served directly and the browser would apply the XSLT transformation itself.
- Use xeplist.xml instead of querying each XEP for name and version - Show XEP number and name in the same column - Show version and latest version in the same column - Show only a Green Checkmark (TM) if the version is up to date - Show a yellow badge with the latest version otherwise
* improve alignment of table elements * show latest version only if it differs from implemented version * add colors for remaining XEP status elements * use color variables
Otherwise it kinds of misses the point of having astylesheet...
In discussion with past contributors...
bkmgit
force-pushed
the
doap3
branch
4 times, most recently
from
963f913 to
a247b94
Compare
|
In this case I think we should just add the new files and not import the git history of the project. |
|
Would file history for just style.xsl be reasonable to import? Could also indicate the origin of the file and previous contributors in the README, though the repository may move/disappear. The XEP list is automatically generated and put on the xmpp.org website, so better to periodically update it, rather than regenerating it. |
I don't think this is needed. If we import a template for latex, libeoffice etc we also don't need the whole history of how the template was changed in the past. From the description on their website it even sounds to me like its expected that people just copy the file. And the history of the file doesn't bring us any benefit as far as I can tell but clutters the repo a bit. @pulkomandy maybe you can advise us here? |
|
Hello, You certainly don't need the entire history. You have to check how you comply with the CC-BY license, I think the README with the authors list and link to the creative commons website for the licene text is good enough but don't trust me on licensing (I would have preferred for this to not require attribution, but apparently that's not possible for some of the contributors). I can add a version tag to the xmpp-doap repo if that makes it easier for you to track which version you're using, which is the only reason I see you'd want to keep some trace of the original git history. You could also consider using a submodule, but I don't think it's worth the extra complications. |
|
Ok, will indicate contributors, original source repository, commit and commit date from the source repository. |
|
Closing in favor of #158 |
6 participants
Closes #133