Fix legal notice on old public domain XEPs

I have no idea if any of this makes sense legally, so just leave it as
it was before (except make it match the DTD so the linter won't
complain).
This commit is contained in:
Sam Whited 2017-01-01 22:41:57 -06:00
parent 0f685c819c
commit e3acaa93f8
6 ha cambiato i file con 19 aggiunte e 14 eliminazioni

Vedi File

@ -3,10 +3,5 @@ addons:
packages:
- xsltproc
- libxml2-utils
before_install:
- wget -O git-ratchet https://github.com/iangrunert/git-ratchet/releases/download/v0.3.1/linux_amd64_git-ratchet
- chmod +x git-ratchet
- git fetch https://github.com/xsf/xeps.git refs/notes/*:refs/notes/*
script:
- make all
- echo "lint,$(xmllint --nonet --noout --noent --loaddtd --valid *.xml 2>&1 | wc -l)" | ./git-ratchet check -v

Vedi File

@ -46,9 +46,7 @@ xep-%.pdf: $(OUTDIR)/xep-%.pdf ;
dependencies: $(OUTDIR)/prettify.css $(OUTDIR)/prettify.js $(OUTDIR)/xmpp.css ;
$(OUTDIR)/%.html: %.xml $(XMLDEPS) dependencies
# TODO: After existing issues are worked out this and the ratcheting CI build
# should be removed and become an error, not just a warning.
xmllint --nonet --noout --noent --loaddtd --valid "$<" || true
xmllint --nonet --noout --noent --loaddtd --valid "$<"
# Check for non-data URIs
! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true
@ -59,9 +57,7 @@ $(OUTDIR)/xmpp.pdf $(OUTDIR)/xmpp-text.pdf:
cp "resources/$(notdir $@)" "$@"
$(OUTDIR)/%.pdf: %.xml $(TEXMLDEPS) $(XMLDEPS) dependencies
# TODO: After existing issues are worked out this and the ratcheting CI build
# should be removed and become an error, not just a warning.
xmllint --nonet --noout --noent --loaddtd --valid "$<" || true
xmllint --nonet --noout --noent --loaddtd --valid "$<"
# Check for non-data URIs
! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true

Vedi File

@ -8,7 +8,7 @@
<header>
<title>Naive Packet Framing Protocol</title>
<abstract>An intermediate method for more efficient framing of the Jabber XML Stream.</abstract>
<legal>This document has been placed in the public domain.</legal>
&PUBLICDOMAINNOTICE;
<number>0017</number>
<status>Rejected</status>
<type>Informational</type>

Vedi File

@ -8,7 +8,7 @@
<header>
<title>Publish/Subscribe</title>
<abstract>A publish-subscribe protocol for Jabber.</abstract>
<legal>This document has been placed in the public domain.</legal>
&PUBLICDOMAINNOTICE;
<number>0024</number>
<status>Retracted</status>
<type>Standards Track</type>

Vedi File

@ -8,7 +8,7 @@
<header>
<title>DSPS - Data Stream Proxy Service</title>
<abstract>A proposal for proxy support in Jabber.</abstract>
<legal>This document has been placed in the public domain.</legal>
&PUBLICDOMAINNOTICE;
<number>0037</number>
<status>Rejected</status>
<type>Standards Track</type>

14
xep.ent
Vedi File

@ -230,6 +230,20 @@ THE SOFTWARE.
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at &lt;<link url='http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/'>http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/</link>&gt; or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).</conformance>
</legal>" >
<!-- NOTE: New XEPs should not use this. Use LEGALNOTICE. -->
<!ENTITY PUBLICDOMAINNOTICE "
<legal>
<copyright>This document has been placed in the public domain.</copyright>
<!-- These probably need to be fixed, but they weren't in the documents this
entity replaces and I have no idea if adding them makes any sense legally.
Needs expert review.
-->
<permissions/>
<warranty/>
<liability/>
<conformance/>
</legal>" >
<!-- other XSF-related text shortcuts -->
<!ENTITY BOOLEANNOTE "<note>In accordance with Section 3.2.2.1 of <cite>XML Schema Part 2: Datatypes</cite>, the allowable lexical representations for the xs:boolean datatype are the strings &quot;0&quot; and &quot;false&quot; for the concept 'false' and the strings &quot;1&quot; and &quot;true&quot; for the concept 'true'; implementations MUST support both styles of lexical representation.</note>" >