diff --git a/404.html b/404.html index 91605686..2488062b 100644 --- a/404.html +++ b/404.html @@ -8,13 +8,13 @@ - + -

404

How did we get here?
+ - + diff --git a/LICENSE.html b/LICENSE.html index fa9dd6b9..3f97c36e 100644 --- a/LICENSE.html +++ b/LICENSE.html @@ -8,7 +8,7 @@ - + @@ -100,6 +100,6 @@ OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to http://unlicense.org (opens new window)

- + diff --git a/assets/js/app.a6c8c475.js b/assets/js/app.062c05ef.js similarity index 99% rename from assets/js/app.a6c8c475.js rename to assets/js/app.062c05ef.js index c5bccedf..15f6e689 100644 --- a/assets/js/app.a6c8c475.js +++ b/assets/js/app.062c05ef.js @@ -5,4 +5,4 @@ * vue-router v3.5.1 * (c) 2021 Evan You * @license MIT - */function Io(t,e){for(var n in e)t[n]=e[n];return t}var Do=/[!'()*]/g,Mo=function(t){return"%"+t.charCodeAt(0).toString(16)},No=/%2C/g,Fo=function(t){return encodeURIComponent(t).replace(Do,Mo).replace(No,",")};function Uo(t){try{return decodeURIComponent(t)}catch(t){0}return t}var Bo=function(t){return null==t||"object"==typeof t?t:String(t)};function Vo(t){var e={};return(t=t.trim().replace(/^(\?|#|&)/,""))?(t.split("&").forEach((function(t){var n=t.replace(/\+/g," ").split("="),r=Uo(n.shift()),o=n.length>0?Uo(n.join("=")):null;void 0===e[r]?e[r]=o:Array.isArray(e[r])?e[r].push(o):e[r]=[e[r],o]})),e):e}function zo(t){var e=t?Object.keys(t).map((function(e){var n=t[e];if(void 0===n)return"";if(null===n)return Fo(e);if(Array.isArray(n)){var r=[];return n.forEach((function(t){void 0!==t&&(null===t?r.push(Fo(e)):r.push(Fo(e)+"="+Fo(t)))})),r.join("&")}return Fo(e)+"="+Fo(n)})).filter((function(t){return t.length>0})).join("&"):null;return e?"?"+e:""}var qo=/\/?$/;function Wo(t,e,n,r){var o=r&&r.options.stringifyQuery,i=e.query||{};try{i=Ho(i)}catch(t){}var a={name:e.name||t&&t.name,meta:t&&t.meta||{},path:e.path||"/",hash:e.hash||"",query:i,params:e.params||{},fullPath:Xo(e,o),matched:t?Ko(t):[]};return n&&(a.redirectedFrom=Xo(n,o)),Object.freeze(a)}function Ho(t){if(Array.isArray(t))return t.map(Ho);if(t&&"object"==typeof t){var e={};for(var n in t)e[n]=Ho(t[n]);return e}return t}var Go=Wo(null,{path:"/"});function Ko(t){for(var e=[];t;)e.unshift(t),t=t.parent;return e}function Xo(t,e){var n=t.path,r=t.query;void 0===r&&(r={});var o=t.hash;return void 0===o&&(o=""),(n||"/")+(e||zo)(r)+o}function Yo(t,e,n){return e===Go?t===e:!!e&&(t.path&&e.path?t.path.replace(qo,"")===e.path.replace(qo,"")&&(n||t.hash===e.hash&&Jo(t.query,e.query)):!(!t.name||!e.name)&&(t.name===e.name&&(n||t.hash===e.hash&&Jo(t.query,e.query)&&Jo(t.params,e.params))))}function Jo(t,e){if(void 0===t&&(t={}),void 0===e&&(e={}),!t||!e)return t===e;var n=Object.keys(t).sort(),r=Object.keys(e).sort();return n.length===r.length&&n.every((function(n,o){var i=t[n];if(r[o]!==n)return!1;var a=e[n];return null==i||null==a?i===a:"object"==typeof i&&"object"==typeof a?Jo(i,a):String(i)===String(a)}))}function Qo(t){for(var e=0;e=0&&(e=t.slice(r),t=t.slice(0,r));var o=t.indexOf("?");return o>=0&&(n=t.slice(o+1),t=t.slice(0,o)),{path:t,query:n,hash:e}}(o.path||""),u=e&&e.path||"/",l=c.path?ei(c.path,u,n||o.append):u,f=function(t,e,n){void 0===e&&(e={});var r,o=n||Vo;try{r=o(t||"")}catch(t){r={}}for(var i in e){var a=e[i];r[i]=Array.isArray(a)?a.map(Bo):Bo(a)}return r}(c.query,o.query,r&&r.options.parseQuery),p=o.hash||c.hash;return p&&"#"!==p.charAt(0)&&(p="#"+p),{_normalized:!0,path:l,query:f,hash:p}}var wi,ki=function(){},Si={name:"RouterLink",props:{to:{type:[String,Object],required:!0},tag:{type:String,default:"a"},custom:Boolean,exact:Boolean,exactPath:Boolean,append:Boolean,replace:Boolean,activeClass:String,exactActiveClass:String,ariaCurrentValue:{type:String,default:"page"},event:{type:[String,Array],default:"click"}},render:function(t){var e=this,n=this.$router,r=this.$route,o=n.resolve(this.to,r,this.append),i=o.location,a=o.route,s=o.href,c={},u=n.options.linkActiveClass,l=n.options.linkExactActiveClass,f=null==u?"router-link-active":u,p=null==l?"router-link-exact-active":l,d=null==this.activeClass?f:this.activeClass,v=null==this.exactActiveClass?p:this.exactActiveClass,h=a.redirectedFrom?Wo(null,_i(a.redirectedFrom),null,n):a;c[v]=Yo(r,h,this.exactPath),c[d]=this.exact||this.exactPath?c[v]:function(t,e){return 0===t.path.replace(qo,"/").indexOf(e.path.replace(qo,"/"))&&(!e.hash||t.hash===e.hash)&&function(t,e){for(var n in e)if(!(n in t))return!1;return!0}(t.query,e.query)}(r,h);var g=c[v]?this.ariaCurrentValue:null,m=function(t){Oi(t)&&(e.replace?n.replace(i,ki):n.push(i,ki))},y={click:Oi};Array.isArray(this.event)?this.event.forEach((function(t){y[t]=m})):y[this.event]=m;var b={class:c},x=!this.$scopedSlots.$hasNormal&&this.$scopedSlots.default&&this.$scopedSlots.default({href:s,route:a,navigate:m,isActive:c[d],isExactActive:c[v]});if(x){if(1===x.length)return x[0];if(x.length>1||!x.length)return 0===x.length?t():t("span",{},x)}if("a"===this.tag)b.on=y,b.attrs={href:s,"aria-current":g};else{var _=function t(e){var n;if(e)for(var r=0;r-1&&(s.params[p]=n.params[p]);return s.path=xi(l.path,s.params),c(l,s,a)}if(s.path){s.params={};for(var d=0;d=t.length?n():t[o]?e(t[o],(function(){r(o+1)})):r(o+1)};r(0)}var Ji={redirected:2,aborted:4,cancelled:8,duplicated:16};function Qi(t,e){return ta(t,e,Ji.redirected,'Redirected when going from "'+t.fullPath+'" to "'+function(t){if("string"==typeof t)return t;if("path"in t)return t.path;var e={};return ea.forEach((function(n){n in t&&(e[n]=t[n])})),JSON.stringify(e,null,2)}(e)+'" via a navigation guard.')}function Zi(t,e){return ta(t,e,Ji.cancelled,'Navigation cancelled from "'+t.fullPath+'" to "'+e.fullPath+'" with a new navigation.')}function ta(t,e,n,r){var o=new Error(r);return o._isRouter=!0,o.from=t,o.to=e,o.type=n,o}var ea=["params","query","hash"];function na(t){return Object.prototype.toString.call(t).indexOf("Error")>-1}function ra(t,e){return na(t)&&t._isRouter&&(null==e||t.type===e)}function oa(t){return function(e,n,r){var o=!1,i=0,a=null;ia(t,(function(t,e,n,s){if("function"==typeof t&&void 0===t.cid){o=!0,i++;var c,u=ca((function(e){var o;((o=e).__esModule||sa&&"Module"===o[Symbol.toStringTag])&&(e=e.default),t.resolved="function"==typeof e?e:wi.extend(e),n.components[s]=e,--i<=0&&r()})),l=ca((function(t){var e="Failed to resolve async component "+s+": "+t;a||(a=na(t)?t:new Error(e),r(a))}));try{c=t(u,l)}catch(t){l(t)}if(c)if("function"==typeof c.then)c.then(u,l);else{var f=c.component;f&&"function"==typeof f.then&&f.then(u,l)}}})),o||r()}}function ia(t,e){return aa(t.map((function(t){return Object.keys(t.components).map((function(n){return e(t.components[n],t.instances[n],t,n)}))})))}function aa(t){return Array.prototype.concat.apply([],t)}var sa="function"==typeof Symbol&&"symbol"==typeof Symbol.toStringTag;function ca(t){var e=!1;return function(){for(var n=[],r=arguments.length;r--;)n[r]=arguments[r];if(!e)return e=!0,t.apply(this,n)}}var ua=function(t,e){this.router=t,this.base=function(t){if(!t)if(Ei){var e=document.querySelector("base");t=(t=e&&e.getAttribute("href")||"/").replace(/^https?:\/\/[^\/]+/,"")}else t="/";"/"!==t.charAt(0)&&(t="/"+t);return t.replace(/\/$/,"")}(e),this.current=Go,this.pending=null,this.ready=!1,this.readyCbs=[],this.readyErrorCbs=[],this.errorCbs=[],this.listeners=[]};function la(t,e,n,r){var o=ia(t,(function(t,r,o,i){var a=function(t,e){"function"!=typeof t&&(t=wi.extend(t));return t.options[e]}(t,e);if(a)return Array.isArray(a)?a.map((function(t){return n(t,r,o,i)})):n(a,r,o,i)}));return aa(r?o.reverse():o)}function fa(t,e){if(e)return function(){return t.apply(e,arguments)}}ua.prototype.listen=function(t){this.cb=t},ua.prototype.onReady=function(t,e){this.ready?t():(this.readyCbs.push(t),e&&this.readyErrorCbs.push(e))},ua.prototype.onError=function(t){this.errorCbs.push(t)},ua.prototype.transitionTo=function(t,e,n){var r,o=this;try{r=this.router.match(t,this.current)}catch(t){throw this.errorCbs.forEach((function(e){e(t)})),t}var i=this.current;this.confirmTransition(r,(function(){o.updateRoute(r),e&&e(r),o.ensureURL(),o.router.afterHooks.forEach((function(t){t&&t(r,i)})),o.ready||(o.ready=!0,o.readyCbs.forEach((function(t){t(r)})))}),(function(t){n&&n(t),t&&!o.ready&&(ra(t,Ji.redirected)&&i===Go||(o.ready=!0,o.readyErrorCbs.forEach((function(e){e(t)}))))}))},ua.prototype.confirmTransition=function(t,e,n){var r=this,o=this.current;this.pending=t;var i,a,s=function(t){!ra(t)&&na(t)&&(r.errorCbs.length?r.errorCbs.forEach((function(e){e(t)})):console.error(t)),n&&n(t)},c=t.matched.length-1,u=o.matched.length-1;if(Yo(t,o)&&c===u&&t.matched[c]===o.matched[u])return this.ensureURL(),s(((a=ta(i=o,t,Ji.duplicated,'Avoided redundant navigation to current location: "'+i.fullPath+'".')).name="NavigationDuplicated",a));var l=function(t,e){var n,r=Math.max(t.length,e.length);for(n=0;n0)){var e=this.router,n=e.options.scrollBehavior,r=Gi&&n;r&&this.listeners.push(Mi());var o=function(){var n=t.current,o=da(t.base);t.current===Go&&o===t._startLocation||t.transitionTo(o,(function(t){r&&Ni(e,t,n,!0)}))};window.addEventListener("popstate",o),this.listeners.push((function(){window.removeEventListener("popstate",o)}))}},e.prototype.go=function(t){window.history.go(t)},e.prototype.push=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){Ki(ni(r.base+t.fullPath)),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){Xi(ni(r.base+t.fullPath)),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.ensureURL=function(t){if(da(this.base)!==this.current.fullPath){var e=ni(this.base+this.current.fullPath);t?Ki(e):Xi(e)}},e.prototype.getCurrentLocation=function(){return da(this.base)},e}(ua);function da(t){var e=window.location.pathname;return t&&0===e.toLowerCase().indexOf(t.toLowerCase())&&(e=e.slice(t.length)),(e||"/")+window.location.search+window.location.hash}var va=function(t){function e(e,n,r){t.call(this,e,n),r&&function(t){var e=da(t);if(!/^\/#/.test(e))return window.location.replace(ni(t+"/#"+e)),!0}(this.base)||ha()}return t&&(e.__proto__=t),e.prototype=Object.create(t&&t.prototype),e.prototype.constructor=e,e.prototype.setupListeners=function(){var t=this;if(!(this.listeners.length>0)){var e=this.router.options.scrollBehavior,n=Gi&&e;n&&this.listeners.push(Mi());var r=function(){var e=t.current;ha()&&t.transitionTo(ga(),(function(r){n&&Ni(t.router,r,e,!0),Gi||ba(r.fullPath)}))},o=Gi?"popstate":"hashchange";window.addEventListener(o,r),this.listeners.push((function(){window.removeEventListener(o,r)}))}},e.prototype.push=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){ya(t.fullPath),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){ba(t.fullPath),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.go=function(t){window.history.go(t)},e.prototype.ensureURL=function(t){var e=this.current.fullPath;ga()!==e&&(t?ya(e):ba(e))},e.prototype.getCurrentLocation=function(){return ga()},e}(ua);function ha(){var t=ga();return"/"===t.charAt(0)||(ba("/"+t),!1)}function ga(){var t=window.location.href,e=t.indexOf("#");return e<0?"":t=t.slice(e+1)}function ma(t){var e=window.location.href,n=e.indexOf("#");return(n>=0?e.slice(0,n):e)+"#"+t}function ya(t){Gi?Ki(ma(t)):window.location.hash=t}function ba(t){Gi?Xi(ma(t)):window.location.replace(ma(t))}var xa=function(t){function e(e,n){t.call(this,e,n),this.stack=[],this.index=-1}return t&&(e.__proto__=t),e.prototype=Object.create(t&&t.prototype),e.prototype.constructor=e,e.prototype.push=function(t,e,n){var r=this;this.transitionTo(t,(function(t){r.stack=r.stack.slice(0,r.index+1).concat(t),r.index++,e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this;this.transitionTo(t,(function(t){r.stack=r.stack.slice(0,r.index).concat(t),e&&e(t)}),n)},e.prototype.go=function(t){var e=this,n=this.index+t;if(!(n<0||n>=this.stack.length)){var r=this.stack[n];this.confirmTransition(r,(function(){var t=e.current;e.index=n,e.updateRoute(r),e.router.afterHooks.forEach((function(e){e&&e(r,t)}))}),(function(t){ra(t,Ji.duplicated)&&(e.index=n)}))}},e.prototype.getCurrentLocation=function(){var t=this.stack[this.stack.length-1];return t?t.fullPath:"/"},e.prototype.ensureURL=function(){},e}(ua),_a=function(t){void 0===t&&(t={}),this.app=null,this.apps=[],this.options=t,this.beforeHooks=[],this.resolveHooks=[],this.afterHooks=[],this.matcher=Ci(t.routes||[],this);var e=t.mode||"hash";switch(this.fallback="history"===e&&!Gi&&!1!==t.fallback,this.fallback&&(e="hash"),Ei||(e="abstract"),this.mode=e,e){case"history":this.history=new pa(this,t.base);break;case"hash":this.history=new va(this,t.base,this.fallback);break;case"abstract":this.history=new xa(this,t.base);break;default:0}},wa={currentRoute:{configurable:!0}};function ka(t,e){return t.push(e),function(){var n=t.indexOf(e);n>-1&&t.splice(n,1)}}_a.prototype.match=function(t,e,n){return this.matcher.match(t,e,n)},wa.currentRoute.get=function(){return this.history&&this.history.current},_a.prototype.init=function(t){var e=this;if(this.apps.push(t),t.$once("hook:destroyed",(function(){var n=e.apps.indexOf(t);n>-1&&e.apps.splice(n,1),e.app===t&&(e.app=e.apps[0]||null),e.app||e.history.teardown()})),!this.app){this.app=t;var n=this.history;if(n instanceof pa||n instanceof va){var r=function(t){n.setupListeners(),function(t){var r=n.current,o=e.options.scrollBehavior;Gi&&o&&"fullPath"in t&&Ni(e,t,r,!1)}(t)};n.transitionTo(n.getCurrentLocation(),r,r)}n.listen((function(t){e.apps.forEach((function(e){e._route=t}))}))}},_a.prototype.beforeEach=function(t){return ka(this.beforeHooks,t)},_a.prototype.beforeResolve=function(t){return ka(this.resolveHooks,t)},_a.prototype.afterEach=function(t){return ka(this.afterHooks,t)},_a.prototype.onReady=function(t,e){this.history.onReady(t,e)},_a.prototype.onError=function(t){this.history.onError(t)},_a.prototype.push=function(t,e,n){var r=this;if(!e&&!n&&"undefined"!=typeof Promise)return new Promise((function(e,n){r.history.push(t,e,n)}));this.history.push(t,e,n)},_a.prototype.replace=function(t,e,n){var r=this;if(!e&&!n&&"undefined"!=typeof Promise)return new Promise((function(e,n){r.history.replace(t,e,n)}));this.history.replace(t,e,n)},_a.prototype.go=function(t){this.history.go(t)},_a.prototype.back=function(){this.go(-1)},_a.prototype.forward=function(){this.go(1)},_a.prototype.getMatchedComponents=function(t){var e=t?t.matched?t:this.resolve(t).route:this.currentRoute;return e?[].concat.apply([],e.matched.map((function(t){return Object.keys(t.components).map((function(e){return t.components[e]}))}))):[]},_a.prototype.resolve=function(t,e,n){var r=_i(t,e=e||this.history.current,n,this),o=this.match(r,e),i=o.redirectedFrom||o.fullPath;return{location:r,route:o,href:function(t,e,n){var r="hash"===n?"#"+e:e;return t?ni(t+"/"+r):r}(this.history.base,i,this.mode),normalizedTo:r,resolved:o}},_a.prototype.getRoutes=function(){return this.matcher.getRoutes()},_a.prototype.addRoute=function(t,e){this.matcher.addRoute(t,e),this.history.current!==Go&&this.history.transitionTo(this.history.getCurrentLocation())},_a.prototype.addRoutes=function(t){this.matcher.addRoutes(t),this.history.current!==Go&&this.history.transitionTo(this.history.getCurrentLocation())},Object.defineProperties(_a.prototype,wa),_a.install=function t(e){if(!t.installed||wi!==e){t.installed=!0,wi=e;var n=function(t){return void 0!==t},r=function(t,e){var r=t.$options._parentVnode;n(r)&&n(r=r.data)&&n(r=r.registerRouteInstance)&&r(t,e)};e.mixin({beforeCreate:function(){n(this.$options.router)?(this._routerRoot=this,this._router=this.$options.router,this._router.init(this),e.util.defineReactive(this,"_route",this._router.history.current)):this._routerRoot=this.$parent&&this.$parent._routerRoot||this,r(this,this)},destroyed:function(){r(this)}}),Object.defineProperty(e.prototype,"$router",{get:function(){return this._routerRoot._router}}),Object.defineProperty(e.prototype,"$route",{get:function(){return this._routerRoot._route}}),e.component("RouterView",Zo),e.component("RouterLink",Si);var o=e.config.optionMergeStrategies;o.beforeRouteEnter=o.beforeRouteLeave=o.beforeRouteUpdate=o.created}},_a.version="3.5.1",_a.isNavigationFailure=ra,_a.NavigationFailureType=Ji,_a.START_LOCATION=Go,Ei&&window.Vue&&window.Vue.use(_a);var Sa=_a;n(201),n(130),n(202),n(96),n(204),n(97),n(98),n(205);function Oa(t){t.locales&&Object.keys(t.locales).forEach((function(e){t.locales[e].path=e})),Object.freeze(t)}n(32),n(33),n(49);var Ea=n(45),ja=(n(136),n(47),n(70),n(177),n(178),{NotFound:function(){return n.e(11).then(n.bind(null,379))},Layout:function(){return Promise.all([n.e(0),n.e(2),n.e(5)]).then(n.bind(null,377))}}),Aa={"v-73c7899f":function(){return n.e(12).then(n.bind(null,382))},"v-0bd5cdc8":function(){return n.e(13).then(n.bind(null,383))},"v-1c3083d7":function(){return n.e(14).then(n.bind(null,384))},"v-5bb87b08":function(){return n.e(15).then(n.bind(null,385))},"v-25cadfd8":function(){return n.e(16).then(n.bind(null,386))},"v-37e789a8":function(){return n.e(17).then(n.bind(null,387))},"v-63068618":function(){return n.e(18).then(n.bind(null,388))},"v-a725d568":function(){return n.e(19).then(n.bind(null,389))},"v-3e2f62e4":function(){return n.e(20).then(n.bind(null,390))},"v-7013f8d4":function(){return n.e(21).then(n.bind(null,391))},"v-7b5776c4":function(){return n.e(22).then(n.bind(null,392))},"v-4dd18066":function(){return n.e(23).then(n.bind(null,393))},"v-73ab052c":function(){return n.e(24).then(n.bind(null,394))},"v-3c19dc8c":function(){return n.e(25).then(n.bind(null,395))},"v-0ea2404c":function(){return n.e(26).then(n.bind(null,396))},"v-d568c068":function(){return n.e(27).then(n.bind(null,397))},"v-62024d2c":function(){return n.e(28).then(n.bind(null,398))},"v-7d3d0b78":function(){return n.e(29).then(n.bind(null,399))},"v-19e3b76c":function(){return Promise.all([n.e(0),n.e(9)]).then(n.bind(null,400))},"v-618643c4":function(){return n.e(30).then(n.bind(null,401))}};function Ca(t){var e=Object.create(null);return function(n){return e[n]||(e[n]=t(n))}}var Pa=/-(\w)/g,Ta=Ca((function(t){return t.replace(Pa,(function(t,e){return e?e.toUpperCase():""}))})),$a=/\B([A-Z])/g,Ra=Ca((function(t){return t.replace($a,"-$1").toLowerCase()})),La=Ca((function(t){return t.charAt(0).toUpperCase()+t.slice(1)}));function Ia(t,e){if(e)return t(e)?t(e):e.includes("-")?t(La(Ta(e))):t(La(e))||t(Ra(e))}var Da=Object.assign({},ja,Aa),Ma=function(t){return Da[t]},Na=function(t){return Aa[t]},Fa=function(t){return ja[t]},Ua=function(t){return Lo.component(t)};function Ba(t){return Ia(Na,t)}function Va(t){return Ia(Fa,t)}function za(t){return Ia(Ma,t)}function qa(t){return Ia(Ua,t)}function Wa(){for(var t=arguments.length,e=new Array(t),n=0;n"})).join("\n "):"",this.$ssrContext.canonicalLink=Za(this.$canonicalUrl)}var e},mounted:function(){this.currentMetaTags=Object(Ea.a)(document.querySelectorAll("meta")),this.updateMeta(),this.updateCanonicalLink()},methods:{updateMeta:function(){document.title=this.$title,document.documentElement.lang=this.$lang;var t=this.getMergedMetaTags();this.currentMetaTags=ts(t,this.currentMetaTags)},getMergedMetaTags:function(){var t=this.$page.frontmatter.meta||[];return Ya()([{name:"description",content:this.$description}],t,this.siteMeta,es)},updateCanonicalLink:function(){Qa(),this.$canonicalUrl&&document.head.insertAdjacentHTML("beforeend",Za(this.$canonicalUrl))}},watch:{$page:function(){this.updateMeta(),this.updateCanonicalLink()}},beforeDestroy:function(){ts(null,this.currentMetaTags),Qa()}};function Qa(){var t=document.querySelector("link[rel='canonical']");t&&t.remove()}function Za(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"";return t?''):""}function ts(t,e){if(e&&Object(Ea.a)(e).filter((function(t){return t.parentNode===document.head})).forEach((function(t){return document.head.removeChild(t)})),t)return t.map((function(t){var e=document.createElement("meta");return Object.keys(t).forEach((function(n){e.setAttribute(n,t[n])})),document.head.appendChild(e),e}))}function es(t){for(var e=0,n=["name","property","itemprop"];e=s.parentElement.offsetTop+10&&(!c||rthis.threshold}},mounted:function(){var t=this;this.scrollTop=this.getScrollTop(),window.addEventListener("scroll",rs()((function(){t.scrollTop=t.getScrollTop()}),100))},methods:{getScrollTop:function(){return window.pageYOffset||document.documentElement.scrollTop||document.body.scrollTop||0},scrollToTop:function(){window.scrollTo({top:0,behavior:"smooth"}),this.scrollTop=0}}},ms=(n(308),Object(ps.a)(gs,(function(){var t=this.$createElement,e=this._self._c||t;return e("transition",{attrs:{name:"fade"}},[this.show?e("svg",{staticClass:"go-to-top",attrs:{xmlns:"http://www.w3.org/2000/svg",viewBox:"0 0 49.484 28.284"},on:{click:this.scrollToTop}},[e("g",{attrs:{transform:"translate(-229 -126.358)"}},[e("rect",{attrs:{fill:"currentColor",width:"35",height:"5",rx:"2",transform:"translate(229 151.107) rotate(-45)"}}),this._v(" "),e("rect",{attrs:{fill:"currentColor",width:"35",height:"5",rx:"2",transform:"translate(274.949 154.642) rotate(-135)"}})])]):this._e()])}),[],!1,null,"5fd4ef0c",null).exports),ys=[function(t){t.router.beforeEach((function(t,e,n){var r={"/simple-data-format":"/tabular-data-package/","/simple-data-format/":"/tabular-data-package/","/implementation":"/guides/implementation"}[t.path];r?n({path:r}):n()}))},{},function(t){t.Vue.mixin({computed:{$dataBlock:function(){return this.$options.__data__block__}}})},{},{},function(t){var e=t.Vue;t.router.options.scrollBehavior=function(t,n,r){if(r)return window.scrollTo({top:r.y,behavior:"smooth"});if(t.hash){if(e.$vuepress.$get("disableScrollBehavior"))return!1;var o=document.querySelector(t.hash);return!!o&&window.scrollTo({top:(i=o,a=document.documentElement,s=a.getBoundingClientRect(),c=i.getBoundingClientRect(),{x:c.left-s.left,y:c.top-s.top}).y,behavior:"smooth"})}return window.scrollTo({top:0,behavior:"smooth"});var i,a,s,c}},function(t){t.Vue.component("BackToTop",ms)}],bs=["BackToTop"];function xs(t,e){if(!(t instanceof e))throw new TypeError("Cannot call a class as a function")}n(309);function _s(t,e){for(var n=0;n2&&void 0!==arguments[2]?arguments[2]:Lo;Oa(e),n.$vuepress.$set("siteData",e);var r=t(n.$vuepress.$get("siteData")),o=new r,i=Object.getOwnPropertyDescriptors(Object.getPrototypeOf(o)),a={};return Object.keys(i).reduce((function(t,e){return e.startsWith("$")&&(t[e]=i[e].get),t}),a),{computed:a}}((function(t){return function(){function e(){xs(this,e)}return ws(e,[{key:"setPage",value:function(t){this.__page=t}},{key:"$site",get:function(){return t}},{key:"$themeConfig",get:function(){return this.$site.themeConfig}},{key:"$frontmatter",get:function(){return this.$page.frontmatter}},{key:"$localeConfig",get:function(){var t,e,n=this.$site.locales,r=void 0===n?{}:n;for(var o in r)"/"===o?e=r[o]:0===this.$page.path.indexOf(o)&&(t=r[o]);return t||e||{}}},{key:"$siteTitle",get:function(){return this.$localeConfig.title||this.$site.title||""}},{key:"$canonicalUrl",get:function(){var t=this.$page.frontmatter.canonicalUrl;return"string"==typeof t&&t}},{key:"$title",get:function(){var t=this.$page,e=this.$page.frontmatter.metaTitle;if("string"==typeof e)return e;var n=this.$siteTitle,r=t.frontmatter.home?null:t.frontmatter.title||t.title;return n?r?r+" | "+n:n:r||"VuePress"}},{key:"$description",get:function(){var t=function(t){if(t){var e=t.filter((function(t){return"description"===t.name}))[0];if(e)return e.content}}(this.$page.frontmatter.meta);return t||(this.$page.frontmatter.description||this.$localeConfig.description||this.$site.description||"")}},{key:"$lang",get:function(){return this.$page.frontmatter.lang||this.$localeConfig.lang||"en-US"}},{key:"$localePath",get:function(){return this.$localeConfig.path||"/"}},{key:"$themeLocaleConfig",get:function(){return(this.$site.themeConfig.locales||{})[this.$localePath]||{}}},{key:"$page",get:function(){return this.__page?this.__page:function(t,e){for(var n=0;n=0&&(e=t.slice(r),t=t.slice(0,r));var o=t.indexOf("?");return o>=0&&(n=t.slice(o+1),t=t.slice(0,o)),{path:t,query:n,hash:e}}(o.path||""),u=e&&e.path||"/",l=c.path?ei(c.path,u,n||o.append):u,f=function(t,e,n){void 0===e&&(e={});var r,o=n||Vo;try{r=o(t||"")}catch(t){r={}}for(var i in e){var a=e[i];r[i]=Array.isArray(a)?a.map(Bo):Bo(a)}return r}(c.query,o.query,r&&r.options.parseQuery),p=o.hash||c.hash;return p&&"#"!==p.charAt(0)&&(p="#"+p),{_normalized:!0,path:l,query:f,hash:p}}var wi,ki=function(){},Si={name:"RouterLink",props:{to:{type:[String,Object],required:!0},tag:{type:String,default:"a"},custom:Boolean,exact:Boolean,exactPath:Boolean,append:Boolean,replace:Boolean,activeClass:String,exactActiveClass:String,ariaCurrentValue:{type:String,default:"page"},event:{type:[String,Array],default:"click"}},render:function(t){var e=this,n=this.$router,r=this.$route,o=n.resolve(this.to,r,this.append),i=o.location,a=o.route,s=o.href,c={},u=n.options.linkActiveClass,l=n.options.linkExactActiveClass,f=null==u?"router-link-active":u,p=null==l?"router-link-exact-active":l,d=null==this.activeClass?f:this.activeClass,v=null==this.exactActiveClass?p:this.exactActiveClass,h=a.redirectedFrom?Wo(null,_i(a.redirectedFrom),null,n):a;c[v]=Yo(r,h,this.exactPath),c[d]=this.exact||this.exactPath?c[v]:function(t,e){return 0===t.path.replace(qo,"/").indexOf(e.path.replace(qo,"/"))&&(!e.hash||t.hash===e.hash)&&function(t,e){for(var n in e)if(!(n in t))return!1;return!0}(t.query,e.query)}(r,h);var g=c[v]?this.ariaCurrentValue:null,m=function(t){Oi(t)&&(e.replace?n.replace(i,ki):n.push(i,ki))},y={click:Oi};Array.isArray(this.event)?this.event.forEach((function(t){y[t]=m})):y[this.event]=m;var b={class:c},x=!this.$scopedSlots.$hasNormal&&this.$scopedSlots.default&&this.$scopedSlots.default({href:s,route:a,navigate:m,isActive:c[d],isExactActive:c[v]});if(x){if(1===x.length)return x[0];if(x.length>1||!x.length)return 0===x.length?t():t("span",{},x)}if("a"===this.tag)b.on=y,b.attrs={href:s,"aria-current":g};else{var _=function t(e){var n;if(e)for(var r=0;r-1&&(s.params[p]=n.params[p]);return s.path=xi(l.path,s.params),c(l,s,a)}if(s.path){s.params={};for(var d=0;d=t.length?n():t[o]?e(t[o],(function(){r(o+1)})):r(o+1)};r(0)}var Ji={redirected:2,aborted:4,cancelled:8,duplicated:16};function Qi(t,e){return ta(t,e,Ji.redirected,'Redirected when going from "'+t.fullPath+'" to "'+function(t){if("string"==typeof t)return t;if("path"in t)return t.path;var e={};return ea.forEach((function(n){n in t&&(e[n]=t[n])})),JSON.stringify(e,null,2)}(e)+'" via a navigation guard.')}function Zi(t,e){return ta(t,e,Ji.cancelled,'Navigation cancelled from "'+t.fullPath+'" to "'+e.fullPath+'" with a new navigation.')}function ta(t,e,n,r){var o=new Error(r);return o._isRouter=!0,o.from=t,o.to=e,o.type=n,o}var ea=["params","query","hash"];function na(t){return Object.prototype.toString.call(t).indexOf("Error")>-1}function ra(t,e){return na(t)&&t._isRouter&&(null==e||t.type===e)}function oa(t){return function(e,n,r){var o=!1,i=0,a=null;ia(t,(function(t,e,n,s){if("function"==typeof t&&void 0===t.cid){o=!0,i++;var c,u=ca((function(e){var o;((o=e).__esModule||sa&&"Module"===o[Symbol.toStringTag])&&(e=e.default),t.resolved="function"==typeof e?e:wi.extend(e),n.components[s]=e,--i<=0&&r()})),l=ca((function(t){var e="Failed to resolve async component "+s+": "+t;a||(a=na(t)?t:new Error(e),r(a))}));try{c=t(u,l)}catch(t){l(t)}if(c)if("function"==typeof c.then)c.then(u,l);else{var f=c.component;f&&"function"==typeof f.then&&f.then(u,l)}}})),o||r()}}function ia(t,e){return aa(t.map((function(t){return Object.keys(t.components).map((function(n){return e(t.components[n],t.instances[n],t,n)}))})))}function aa(t){return Array.prototype.concat.apply([],t)}var sa="function"==typeof Symbol&&"symbol"==typeof Symbol.toStringTag;function ca(t){var e=!1;return function(){for(var n=[],r=arguments.length;r--;)n[r]=arguments[r];if(!e)return e=!0,t.apply(this,n)}}var ua=function(t,e){this.router=t,this.base=function(t){if(!t)if(Ei){var e=document.querySelector("base");t=(t=e&&e.getAttribute("href")||"/").replace(/^https?:\/\/[^\/]+/,"")}else t="/";"/"!==t.charAt(0)&&(t="/"+t);return t.replace(/\/$/,"")}(e),this.current=Go,this.pending=null,this.ready=!1,this.readyCbs=[],this.readyErrorCbs=[],this.errorCbs=[],this.listeners=[]};function la(t,e,n,r){var o=ia(t,(function(t,r,o,i){var a=function(t,e){"function"!=typeof t&&(t=wi.extend(t));return t.options[e]}(t,e);if(a)return Array.isArray(a)?a.map((function(t){return n(t,r,o,i)})):n(a,r,o,i)}));return aa(r?o.reverse():o)}function fa(t,e){if(e)return function(){return t.apply(e,arguments)}}ua.prototype.listen=function(t){this.cb=t},ua.prototype.onReady=function(t,e){this.ready?t():(this.readyCbs.push(t),e&&this.readyErrorCbs.push(e))},ua.prototype.onError=function(t){this.errorCbs.push(t)},ua.prototype.transitionTo=function(t,e,n){var r,o=this;try{r=this.router.match(t,this.current)}catch(t){throw this.errorCbs.forEach((function(e){e(t)})),t}var i=this.current;this.confirmTransition(r,(function(){o.updateRoute(r),e&&e(r),o.ensureURL(),o.router.afterHooks.forEach((function(t){t&&t(r,i)})),o.ready||(o.ready=!0,o.readyCbs.forEach((function(t){t(r)})))}),(function(t){n&&n(t),t&&!o.ready&&(ra(t,Ji.redirected)&&i===Go||(o.ready=!0,o.readyErrorCbs.forEach((function(e){e(t)}))))}))},ua.prototype.confirmTransition=function(t,e,n){var r=this,o=this.current;this.pending=t;var i,a,s=function(t){!ra(t)&&na(t)&&(r.errorCbs.length?r.errorCbs.forEach((function(e){e(t)})):console.error(t)),n&&n(t)},c=t.matched.length-1,u=o.matched.length-1;if(Yo(t,o)&&c===u&&t.matched[c]===o.matched[u])return this.ensureURL(),s(((a=ta(i=o,t,Ji.duplicated,'Avoided redundant navigation to current location: "'+i.fullPath+'".')).name="NavigationDuplicated",a));var l=function(t,e){var n,r=Math.max(t.length,e.length);for(n=0;n0)){var e=this.router,n=e.options.scrollBehavior,r=Gi&&n;r&&this.listeners.push(Mi());var o=function(){var n=t.current,o=da(t.base);t.current===Go&&o===t._startLocation||t.transitionTo(o,(function(t){r&&Ni(e,t,n,!0)}))};window.addEventListener("popstate",o),this.listeners.push((function(){window.removeEventListener("popstate",o)}))}},e.prototype.go=function(t){window.history.go(t)},e.prototype.push=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){Ki(ni(r.base+t.fullPath)),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){Xi(ni(r.base+t.fullPath)),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.ensureURL=function(t){if(da(this.base)!==this.current.fullPath){var e=ni(this.base+this.current.fullPath);t?Ki(e):Xi(e)}},e.prototype.getCurrentLocation=function(){return da(this.base)},e}(ua);function da(t){var e=window.location.pathname;return t&&0===e.toLowerCase().indexOf(t.toLowerCase())&&(e=e.slice(t.length)),(e||"/")+window.location.search+window.location.hash}var va=function(t){function e(e,n,r){t.call(this,e,n),r&&function(t){var e=da(t);if(!/^\/#/.test(e))return window.location.replace(ni(t+"/#"+e)),!0}(this.base)||ha()}return t&&(e.__proto__=t),e.prototype=Object.create(t&&t.prototype),e.prototype.constructor=e,e.prototype.setupListeners=function(){var t=this;if(!(this.listeners.length>0)){var e=this.router.options.scrollBehavior,n=Gi&&e;n&&this.listeners.push(Mi());var r=function(){var e=t.current;ha()&&t.transitionTo(ga(),(function(r){n&&Ni(t.router,r,e,!0),Gi||ba(r.fullPath)}))},o=Gi?"popstate":"hashchange";window.addEventListener(o,r),this.listeners.push((function(){window.removeEventListener(o,r)}))}},e.prototype.push=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){ya(t.fullPath),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this,o=this.current;this.transitionTo(t,(function(t){ba(t.fullPath),Ni(r.router,t,o,!1),e&&e(t)}),n)},e.prototype.go=function(t){window.history.go(t)},e.prototype.ensureURL=function(t){var e=this.current.fullPath;ga()!==e&&(t?ya(e):ba(e))},e.prototype.getCurrentLocation=function(){return ga()},e}(ua);function ha(){var t=ga();return"/"===t.charAt(0)||(ba("/"+t),!1)}function ga(){var t=window.location.href,e=t.indexOf("#");return e<0?"":t=t.slice(e+1)}function ma(t){var e=window.location.href,n=e.indexOf("#");return(n>=0?e.slice(0,n):e)+"#"+t}function ya(t){Gi?Ki(ma(t)):window.location.hash=t}function ba(t){Gi?Xi(ma(t)):window.location.replace(ma(t))}var xa=function(t){function e(e,n){t.call(this,e,n),this.stack=[],this.index=-1}return t&&(e.__proto__=t),e.prototype=Object.create(t&&t.prototype),e.prototype.constructor=e,e.prototype.push=function(t,e,n){var r=this;this.transitionTo(t,(function(t){r.stack=r.stack.slice(0,r.index+1).concat(t),r.index++,e&&e(t)}),n)},e.prototype.replace=function(t,e,n){var r=this;this.transitionTo(t,(function(t){r.stack=r.stack.slice(0,r.index).concat(t),e&&e(t)}),n)},e.prototype.go=function(t){var e=this,n=this.index+t;if(!(n<0||n>=this.stack.length)){var r=this.stack[n];this.confirmTransition(r,(function(){var t=e.current;e.index=n,e.updateRoute(r),e.router.afterHooks.forEach((function(e){e&&e(r,t)}))}),(function(t){ra(t,Ji.duplicated)&&(e.index=n)}))}},e.prototype.getCurrentLocation=function(){var t=this.stack[this.stack.length-1];return t?t.fullPath:"/"},e.prototype.ensureURL=function(){},e}(ua),_a=function(t){void 0===t&&(t={}),this.app=null,this.apps=[],this.options=t,this.beforeHooks=[],this.resolveHooks=[],this.afterHooks=[],this.matcher=Ci(t.routes||[],this);var e=t.mode||"hash";switch(this.fallback="history"===e&&!Gi&&!1!==t.fallback,this.fallback&&(e="hash"),Ei||(e="abstract"),this.mode=e,e){case"history":this.history=new pa(this,t.base);break;case"hash":this.history=new va(this,t.base,this.fallback);break;case"abstract":this.history=new xa(this,t.base);break;default:0}},wa={currentRoute:{configurable:!0}};function ka(t,e){return t.push(e),function(){var n=t.indexOf(e);n>-1&&t.splice(n,1)}}_a.prototype.match=function(t,e,n){return this.matcher.match(t,e,n)},wa.currentRoute.get=function(){return this.history&&this.history.current},_a.prototype.init=function(t){var e=this;if(this.apps.push(t),t.$once("hook:destroyed",(function(){var n=e.apps.indexOf(t);n>-1&&e.apps.splice(n,1),e.app===t&&(e.app=e.apps[0]||null),e.app||e.history.teardown()})),!this.app){this.app=t;var n=this.history;if(n instanceof pa||n instanceof va){var r=function(t){n.setupListeners(),function(t){var r=n.current,o=e.options.scrollBehavior;Gi&&o&&"fullPath"in t&&Ni(e,t,r,!1)}(t)};n.transitionTo(n.getCurrentLocation(),r,r)}n.listen((function(t){e.apps.forEach((function(e){e._route=t}))}))}},_a.prototype.beforeEach=function(t){return ka(this.beforeHooks,t)},_a.prototype.beforeResolve=function(t){return ka(this.resolveHooks,t)},_a.prototype.afterEach=function(t){return ka(this.afterHooks,t)},_a.prototype.onReady=function(t,e){this.history.onReady(t,e)},_a.prototype.onError=function(t){this.history.onError(t)},_a.prototype.push=function(t,e,n){var r=this;if(!e&&!n&&"undefined"!=typeof Promise)return new Promise((function(e,n){r.history.push(t,e,n)}));this.history.push(t,e,n)},_a.prototype.replace=function(t,e,n){var r=this;if(!e&&!n&&"undefined"!=typeof Promise)return new Promise((function(e,n){r.history.replace(t,e,n)}));this.history.replace(t,e,n)},_a.prototype.go=function(t){this.history.go(t)},_a.prototype.back=function(){this.go(-1)},_a.prototype.forward=function(){this.go(1)},_a.prototype.getMatchedComponents=function(t){var e=t?t.matched?t:this.resolve(t).route:this.currentRoute;return e?[].concat.apply([],e.matched.map((function(t){return Object.keys(t.components).map((function(e){return t.components[e]}))}))):[]},_a.prototype.resolve=function(t,e,n){var r=_i(t,e=e||this.history.current,n,this),o=this.match(r,e),i=o.redirectedFrom||o.fullPath;return{location:r,route:o,href:function(t,e,n){var r="hash"===n?"#"+e:e;return t?ni(t+"/"+r):r}(this.history.base,i,this.mode),normalizedTo:r,resolved:o}},_a.prototype.getRoutes=function(){return this.matcher.getRoutes()},_a.prototype.addRoute=function(t,e){this.matcher.addRoute(t,e),this.history.current!==Go&&this.history.transitionTo(this.history.getCurrentLocation())},_a.prototype.addRoutes=function(t){this.matcher.addRoutes(t),this.history.current!==Go&&this.history.transitionTo(this.history.getCurrentLocation())},Object.defineProperties(_a.prototype,wa),_a.install=function t(e){if(!t.installed||wi!==e){t.installed=!0,wi=e;var n=function(t){return void 0!==t},r=function(t,e){var r=t.$options._parentVnode;n(r)&&n(r=r.data)&&n(r=r.registerRouteInstance)&&r(t,e)};e.mixin({beforeCreate:function(){n(this.$options.router)?(this._routerRoot=this,this._router=this.$options.router,this._router.init(this),e.util.defineReactive(this,"_route",this._router.history.current)):this._routerRoot=this.$parent&&this.$parent._routerRoot||this,r(this,this)},destroyed:function(){r(this)}}),Object.defineProperty(e.prototype,"$router",{get:function(){return this._routerRoot._router}}),Object.defineProperty(e.prototype,"$route",{get:function(){return this._routerRoot._route}}),e.component("RouterView",Zo),e.component("RouterLink",Si);var o=e.config.optionMergeStrategies;o.beforeRouteEnter=o.beforeRouteLeave=o.beforeRouteUpdate=o.created}},_a.version="3.5.1",_a.isNavigationFailure=ra,_a.NavigationFailureType=Ji,_a.START_LOCATION=Go,Ei&&window.Vue&&window.Vue.use(_a);var Sa=_a;n(201),n(130),n(202),n(96),n(204),n(97),n(98),n(205);function Oa(t){t.locales&&Object.keys(t.locales).forEach((function(e){t.locales[e].path=e})),Object.freeze(t)}n(32),n(33),n(49);var Ea=n(45),ja=(n(136),n(47),n(70),n(177),n(178),{NotFound:function(){return n.e(11).then(n.bind(null,379))},Layout:function(){return Promise.all([n.e(0),n.e(2),n.e(5)]).then(n.bind(null,377))}}),Aa={"v-73c7899f":function(){return n.e(12).then(n.bind(null,382))},"v-0bd5cdc8":function(){return n.e(13).then(n.bind(null,383))},"v-1c3083d7":function(){return n.e(14).then(n.bind(null,384))},"v-5bb87b08":function(){return n.e(15).then(n.bind(null,385))},"v-25cadfd8":function(){return n.e(16).then(n.bind(null,386))},"v-37e789a8":function(){return n.e(17).then(n.bind(null,387))},"v-63068618":function(){return n.e(18).then(n.bind(null,388))},"v-a725d568":function(){return n.e(19).then(n.bind(null,389))},"v-3e2f62e4":function(){return n.e(20).then(n.bind(null,390))},"v-7013f8d4":function(){return n.e(21).then(n.bind(null,391))},"v-7b5776c4":function(){return n.e(22).then(n.bind(null,392))},"v-4dd18066":function(){return n.e(23).then(n.bind(null,393))},"v-73ab052c":function(){return n.e(24).then(n.bind(null,394))},"v-3c19dc8c":function(){return n.e(25).then(n.bind(null,395))},"v-0ea2404c":function(){return n.e(26).then(n.bind(null,396))},"v-d568c068":function(){return n.e(27).then(n.bind(null,397))},"v-62024d2c":function(){return n.e(28).then(n.bind(null,398))},"v-7d3d0b78":function(){return n.e(29).then(n.bind(null,399))},"v-19e3b76c":function(){return Promise.all([n.e(0),n.e(9)]).then(n.bind(null,400))},"v-618643c4":function(){return n.e(30).then(n.bind(null,401))}};function Ca(t){var e=Object.create(null);return function(n){return e[n]||(e[n]=t(n))}}var Pa=/-(\w)/g,Ta=Ca((function(t){return t.replace(Pa,(function(t,e){return e?e.toUpperCase():""}))})),$a=/\B([A-Z])/g,Ra=Ca((function(t){return t.replace($a,"-$1").toLowerCase()})),La=Ca((function(t){return t.charAt(0).toUpperCase()+t.slice(1)}));function Ia(t,e){if(e)return t(e)?t(e):e.includes("-")?t(La(Ta(e))):t(La(e))||t(Ra(e))}var Da=Object.assign({},ja,Aa),Ma=function(t){return Da[t]},Na=function(t){return Aa[t]},Fa=function(t){return ja[t]},Ua=function(t){return Lo.component(t)};function Ba(t){return Ia(Na,t)}function Va(t){return Ia(Fa,t)}function za(t){return Ia(Ma,t)}function qa(t){return Ia(Ua,t)}function Wa(){for(var t=arguments.length,e=new Array(t),n=0;n"})).join("\n "):"",this.$ssrContext.canonicalLink=Za(this.$canonicalUrl)}var e},mounted:function(){this.currentMetaTags=Object(Ea.a)(document.querySelectorAll("meta")),this.updateMeta(),this.updateCanonicalLink()},methods:{updateMeta:function(){document.title=this.$title,document.documentElement.lang=this.$lang;var t=this.getMergedMetaTags();this.currentMetaTags=ts(t,this.currentMetaTags)},getMergedMetaTags:function(){var t=this.$page.frontmatter.meta||[];return Ya()([{name:"description",content:this.$description}],t,this.siteMeta,es)},updateCanonicalLink:function(){Qa(),this.$canonicalUrl&&document.head.insertAdjacentHTML("beforeend",Za(this.$canonicalUrl))}},watch:{$page:function(){this.updateMeta(),this.updateCanonicalLink()}},beforeDestroy:function(){ts(null,this.currentMetaTags),Qa()}};function Qa(){var t=document.querySelector("link[rel='canonical']");t&&t.remove()}function Za(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"";return t?''):""}function ts(t,e){if(e&&Object(Ea.a)(e).filter((function(t){return t.parentNode===document.head})).forEach((function(t){return document.head.removeChild(t)})),t)return t.map((function(t){var e=document.createElement("meta");return Object.keys(t).forEach((function(n){e.setAttribute(n,t[n])})),document.head.appendChild(e),e}))}function es(t){for(var e=0,n=["name","property","itemprop"];e=s.parentElement.offsetTop+10&&(!c||rthis.threshold}},mounted:function(){var t=this;this.scrollTop=this.getScrollTop(),window.addEventListener("scroll",rs()((function(){t.scrollTop=t.getScrollTop()}),100))},methods:{getScrollTop:function(){return window.pageYOffset||document.documentElement.scrollTop||document.body.scrollTop||0},scrollToTop:function(){window.scrollTo({top:0,behavior:"smooth"}),this.scrollTop=0}}},ms=(n(308),Object(ps.a)(gs,(function(){var t=this.$createElement,e=this._self._c||t;return e("transition",{attrs:{name:"fade"}},[this.show?e("svg",{staticClass:"go-to-top",attrs:{xmlns:"http://www.w3.org/2000/svg",viewBox:"0 0 49.484 28.284"},on:{click:this.scrollToTop}},[e("g",{attrs:{transform:"translate(-229 -126.358)"}},[e("rect",{attrs:{fill:"currentColor",width:"35",height:"5",rx:"2",transform:"translate(229 151.107) rotate(-45)"}}),this._v(" "),e("rect",{attrs:{fill:"currentColor",width:"35",height:"5",rx:"2",transform:"translate(274.949 154.642) rotate(-135)"}})])]):this._e()])}),[],!1,null,"5fd4ef0c",null).exports),ys=[function(t){t.router.beforeEach((function(t,e,n){var r={"/simple-data-format":"/tabular-data-package/","/simple-data-format/":"/tabular-data-package/","/implementation":"/guides/implementation"}[t.path];r?n({path:r}):n()}))},{},function(t){t.Vue.mixin({computed:{$dataBlock:function(){return this.$options.__data__block__}}})},{},{},function(t){var e=t.Vue;t.router.options.scrollBehavior=function(t,n,r){if(r)return window.scrollTo({top:r.y,behavior:"smooth"});if(t.hash){if(e.$vuepress.$get("disableScrollBehavior"))return!1;var o=document.querySelector(t.hash);return!!o&&window.scrollTo({top:(i=o,a=document.documentElement,s=a.getBoundingClientRect(),c=i.getBoundingClientRect(),{x:c.left-s.left,y:c.top-s.top}).y,behavior:"smooth"})}return window.scrollTo({top:0,behavior:"smooth"});var i,a,s,c}},function(t){t.Vue.component("BackToTop",ms)}],bs=["BackToTop"];function xs(t,e){if(!(t instanceof e))throw new TypeError("Cannot call a class as a function")}n(309);function _s(t,e){for(var n=0;n2&&void 0!==arguments[2]?arguments[2]:Lo;Oa(e),n.$vuepress.$set("siteData",e);var r=t(n.$vuepress.$get("siteData")),o=new r,i=Object.getOwnPropertyDescriptors(Object.getPrototypeOf(o)),a={};return Object.keys(i).reduce((function(t,e){return e.startsWith("$")&&(t[e]=i[e].get),t}),a),{computed:a}}((function(t){return function(){function e(){xs(this,e)}return ws(e,[{key:"setPage",value:function(t){this.__page=t}},{key:"$site",get:function(){return t}},{key:"$themeConfig",get:function(){return this.$site.themeConfig}},{key:"$frontmatter",get:function(){return this.$page.frontmatter}},{key:"$localeConfig",get:function(){var t,e,n=this.$site.locales,r=void 0===n?{}:n;for(var o in r)"/"===o?e=r[o]:0===this.$page.path.indexOf(o)&&(t=r[o]);return t||e||{}}},{key:"$siteTitle",get:function(){return this.$localeConfig.title||this.$site.title||""}},{key:"$canonicalUrl",get:function(){var t=this.$page.frontmatter.canonicalUrl;return"string"==typeof t&&t}},{key:"$title",get:function(){var t=this.$page,e=this.$page.frontmatter.metaTitle;if("string"==typeof e)return e;var n=this.$siteTitle,r=t.frontmatter.home?null:t.frontmatter.title||t.title;return n?r?r+" | "+n:n:r||"VuePress"}},{key:"$description",get:function(){var t=function(t){if(t){var e=t.filter((function(t){return"description"===t.name}))[0];if(e)return e.content}}(this.$page.frontmatter.meta);return t||(this.$page.frontmatter.description||this.$localeConfig.description||this.$site.description||"")}},{key:"$lang",get:function(){return this.$page.frontmatter.lang||this.$localeConfig.lang||"en-US"}},{key:"$localePath",get:function(){return this.$localeConfig.path||"/"}},{key:"$themeLocaleConfig",get:function(){return(this.$site.themeConfig.locales||{})[this.$localePath]||{}}},{key:"$page",get:function(){return this.__page?this.__page:function(t,e){for(var n=0;n - + @@ -117,6 +117,6 @@

# Product pages

hexagon:
 github: # list of github repos ...
Edit this page (opens new window)
Last Updated: 2/17/2020, 12:56:48 PM
- + diff --git a/csv-dialect/index.html b/csv-dialect/index.html index 61ee6a7e..70937459 100644 --- a/csv-dialect/index.html +++ b/csv-dialect/index.html @@ -8,7 +8,7 @@ - + @@ -98,6 +98,6 @@ } }
- + diff --git a/data-package-identifier/index.html b/data-package-identifier/index.html index 5f61f455..5d285693 100644 --- a/data-package-identifier/index.html +++ b/data-package-identifier/index.html @@ -8,7 +8,7 @@ - + @@ -105,6 +105,6 @@ original: }

It can be parsed (and less importantly) serialized to a simple string. Spec strings will be frequently used on e.g. the command line to identify a data package.

# Identifier String

An Identifier String is a single string (rather than JSON object) that points to a Data Package. An Identifier String can be, in decreasing order of explicitness:

  • A URL that points directly to the datapackage.json (no resolution needed):

http://mywebsite.com/mydatapackage/datapackage.json (opens new window)

  • A URL that points directly to the Data Package (that is, the directory containing the datapackage.json):

http://mywebsite.com/mydatapackage/ (opens new window)

resolves to:

http://mywebsite.com/mydatapackage/datapackage.json (opens new window)

  • A GitHub URL:

http://github.com/datasets/gold-prices (opens new window)

resolves to:

https://raw.githubusercontent.com/datasets/gold-prices/master/datapackage.json (opens new window)

gold-prices

resolves to:

https://datahub.io/core/gold-prices/datapackage.json (opens new window)

- + diff --git a/data-package/index.html b/data-package/index.html index 8abff5d3..9daf10e4 100644 --- a/data-package/index.html +++ b/data-package/index.html @@ -8,7 +8,7 @@ - + @@ -150,6 +150,6 @@ "created": "1985-04-12T23:20:50.52Z" }
Edit this page (opens new window)
Last Updated: 10/11/2022, 4:12:07 PM
- + diff --git a/data-resource/index.html b/data-resource/index.html index cdd093a9..65cccac9 100644 --- a/data-resource/index.html +++ b/data-resource/index.html @@ -8,7 +8,7 @@ - + @@ -166,6 +166,6 @@ the hash’s value with the algorithm name in lower-case. For example:

"hash": "sha1:8843d7f92416211de9ebb963ff4ce28125932878"

  • sources: as for Data Package metadata.

  • licenses: as for Data Package metadata. If not specified the resource
    inherits from the data package.

    • # Resource Schemas

    A Data Resource MAY have a schema property to describe the schema of the resource data.

    The value for the schema property on a resource MUST be an object representing the schema OR a string that identifies the location of the schema.

    If a string it must be a url-or-path as defined above, that is a fully qualified http URL or a relative POSIX path. The file at the location specified by this url-or-path string MUST be a JSON document containing the schema.

    NOTE: the Data Package specification places no restrictions on the form of the schema Object. This flexibility enables specific communities to define schemas appropriate for the data they manage. As an example, the Tabular Data Package specification requires the schema to conform to Table Schema.

    - + diff --git a/fiscal-data-package--budgets/index.html b/fiscal-data-package--budgets/index.html index f50ce0d2..63b1b3ef 100644 --- a/fiscal-data-package--budgets/index.html +++ b/fiscal-data-package--budgets/index.html @@ -8,7 +8,7 @@ - + @@ -87,6 +87,6 @@ (opens new window)

    WARNING

    This is a draft specification and still under development. If you have comments or suggestions please file them in the issue tracker (opens new window). If you have explicit changes please fork the git repo (opens new window) and submit a pull request.

    # Fiscal Data Package - Budget Standard Taxonomy

    The Budget Taxonomy is a set of ColumnTypes to be used in the context of a Fiscal Data Package to describe budget data of organizations (governments or otherwise.)

    Author(s)
    Created 14 March 2014
    Updated 22 April 2018
    JSON Schema fiscal-data-package-budgets.json
    Version 1.0-rc.1

    # Language

    The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119

    # Changelog

    • 1.0.0rc1: Initial text

    # Introduction

    This document contains a ColumnType taxonomy to be used for publishing budget data files.

    The ColumnTypes contained in this taxonomy contain:

    • Generic value types
    • Generic time types as well as the more specific ‘fiscal year’ type
    • Classifications:
      • Functional: COFOG and Generic
      • Economic: GFSM and Generic
      • Administrative
      • Activity
    • Other Budgeting-related Properties
    • Geo-Related types

    # References

    # Location

    The canonic location for this taxonomy’s ColumnType definition - to be used in fiscal data package descriptors - is

    https://specs.frictionlessdata.io/taxonomies/fiscal/budgets.json

    # The Taxonomy

    # Amounts and their properties

    # value

    Numeric value depicting a fiscal amount related to the budget item, spending transaction etc.

    • dataType: number
    # value-kind:code

    Unique identifier for the amount kind

    • dataType: string
    • unique: True
    # value-kind:label

    Display name for the amount kind

    • dataType: string
    • labelOf: value-kind:code
    # value-currency:code

    Unique identifier for the amount currency

    • dataType: string
    • unique: True
    # value-currency:label

    Display name for the amount currency

    • dataType: string
    • labelOf: value-kind:code

    # Time Indication

    # date:fiscal-year

    The fiscal-year for which the values in this record are relevant

    • dataType: integer
    • unique: True
    # date:fiscal:activity-approval

    The approval date of a specific activity

    • dataType: date
    • unique: True
    # date:fiscal:activity-end

    The ending date of a specific activity

    • dataType: date
    • unique: True
    # date:fiscal:activity-start

    The starting date of a specific activity

    • dataType: date
    • unique: True
    # date:fiscal:final-payment

    The date of the last payment for a specific activity

    • dataType: date
    • unique: True
    # date:fiscal:first-payment

    The date of the first payment for a specific activity

    • dataType: date
    • unique: True
    # date:generic

    An non-specific date related to the values in this record (e.g. transaction date etc.)

    • dataType: date
    • unique: True

    # Classifications: Functional (COFOG)

    # functional-classification:cofog:class:code

    The COFOG ‘Class’ Level code

    • dataType: string
    • prior: functional-classification:cofog:group:code
    • unique: True
    # functional-classification:cofog:class:description

    A more detailed textual description for this class

    • dataType: string
    # functional-classification:cofog:class:label

    A label or display name for this class

    • dataType: string
    • labelOf: functional-classification:cofog:class:code
    # functional-classification:cofog:code

    The complete COFOG classification code, non level-specific

    • dataType: string
    • unique: True
    # functional-classification:cofog:description

    Description for this COFOG classification, non level-specific

    • dataType: string
    # functional-classification:cofog:division:code

    The COFOG ‘Division’ Level code

    • dataType: string
    • unique: True
    # functional-classification:cofog:division:description

    A more detailed textual description for this division

    • dataType: string
    # functional-classification:cofog:division:label

    A label or display name for this division

    • dataType: string
    • labelOf: functional-classification:cofog:division:code
    # functional-classification:cofog:group:code

    The COFOG ‘Group’ Level code

    • dataType: string
    • prior: functional-classification:cofog:division:code
    • unique: True
    # functional-classification:cofog:group:description

    A more detailed textual description for this group

    • dataType: string
    # functional-classification:cofog:group:label

    A label or display name for this group

    • dataType: string
    • labelOf: functional-classification:cofog:group:code
    # functional-classification:cofog:label

    Display name for this COFOG classification, non level-specific

    • dataType: string
    • labelOf: functional-classification:cofog:code

    # Classifications: Functional (non-specific)

    # functional-classification:generic:code

    A code or unique identifier for the classification (not level specific)

    • dataType: string
    • unique: True
    # functional-classification:generic:description

    A longer descriptive text for this classification

    • dataType: string
    # functional-classification:generic:label

    A label, title or display name for the classification

    • dataType: string
    • labelOf: functional-classification:generic:code
    # functional-classification:generic:level{1..8}:code

    A code or unique identifier for the top level of the classification

    • dataType: string
    • unique: True
    # functional-classification:generic:level{1..8}:description

    A longer descriptive text for this level of the classification

    • dataType: string
    # functional-classification:generic:level{1..8}:label

    A label, title or display name for this level of the classification

    • dataType: string
    • labelOf: functional-classification:generic:level1:code

    # Classifications: Economic (GFSM)

    # economic-classification:gfsm:level{1..4}:code

    A code or unique identifier for the top level of the classification

    • dataType: string
    • unique: True
    # economic-classification:gfsm:level{1..4}:description

    A longer descriptive text for this level of the classification

    • dataType: string
    # economic-classification:gfsm:level{1..4}:label

    A label, title or display name for this level of the classification

    • dataType: string
    • labelOf: economic-classification:gfsm:level1:code

    # Classifications: Economic (non-specific)

    # economic-classification:generic:code

    A code or unique identifier for the classification (not level specific)

    • dataType: string
    • unique: True
    # economic-classification:generic:description

    A longer descriptive text for this classification

    • dataType: string
    # economic-classification:generic:label

    A label, title or display name for the classification

    • dataType: string
    • labelOf: economic-classification:generic:code
    # economic-classification:generic:level{1..4}:code

    A code or unique identifier for the top level of the classification

    • dataType: string
    • unique: True
    # economic-classification:generic:level{1..4}:description

    A longer descriptive text for this level of the classification

    • dataType: string
    # economic-classification:generic:level{1..4}:label

    A label, title or display name for this level of the classification

    • dataType: string
    • labelOf: economic-classification:generic:level1:code

    # Classifications: Administrative

    # administrative-classification:generic:code

    A code or unique identifier for the classification (not level specific)

    • dataType: string
    • unique: True
    # administrative-classification:generic:description

    A longer descriptive text for this classification

    • dataType: string
    # administrative-classification:generic:label

    A label, title or display name for the classification

    • dataType: string
    • labelOf: administrative-classification:generic:code
    # administrative-classification:generic:level{1..8}:code

    A code or unique identifier for the top level of the classification

    • dataType: string
    • unique: True
    # administrative-classification:generic:level{1..8}:description

    A longer descriptive text for this level of the classification

    • dataType: string
    # administrative-classification:generic:level{1..8}:label

    A label, title or display name for this level of the classification

    • dataType: string
    • labelOf: administrative-classification:generic:level1:code
    # activity:generic:contract:code

    A code or unique identifier for the contract

    • dataType: string
    • prior: activity:generic:subproject:code
    • unique: True
    # activity:generic:contract:label

    A label, title or display name for this contract

    • dataType: string
    • labelOf: activity:generic:contract:code
    # activity:generic:program:code

    A code or unique identifier for the program

    • dataType: string
    • unique: True
    # activity:generic:program:label

    A label, title or display name for this program

    • dataType: string
    • labelOf: activity:generic:program:code
    # activity:generic:project:code

    A code or unique identifier for the project

    • dataType: string
    • prior: activity:generic:subprogram:code
    • unique: True
    # activity:generic:project:label

    A label, title or display name for this project

    • dataType: string
    • labelOf: activity:generic:project:code
    # activity:generic:subprogram:code

    A code or unique identifier for the subprogram

    • dataType: string
    • prior: activity:generic:program:code
    • unique: True
    # activity:generic:subprogram:label

    A label, title or display name for this subprogram

    • dataType: string
    • labelOf: activity:generic:subprogram:code
    # activity:generic:subproject:code

    A code or unique identifier for the sub-project

    • dataType: string
    • prior: activity:generic:project:code
    • unique: True
    # activity:generic:subproject:label

    A label, title or display name for this sub-project

    • dataType: string
    • labelOf: activity:generic:subproject:code
    # budget-line-id

    A unique identifier for this budget line

    • dataType: string
    • unique: True
    # budgetary-transfers

    Extra properties regarding whether the expenditure contains budgetary transfers

    • dataType: string
    # direction

    Specifies whether the values in this line are expenditure or revenues

    • dataType: string
    • unique: True
    # phase:id

    The phase identifier

    • dataType: string
    • unique: True
    # phase:label

    The phase display name

    • dataType: string
    • labelOf: phase:id
    # expenditure-type:code

    Unique identifier for the expenditure type

    • dataType: string
    • unique: True
    # expenditure-type:label

    Display name for the expenditure type

    • dataType: string
    • labelOf: expenditure-type:code
    # fin-source:generic:code

    A code or unique identifier for the financial source

    • dataType: string
    • unique: True
    # fin-source:generic:label

    Display name or title for the financial source

    • dataType: string
    • labelOf: fin-source:generic:code
    # fin-source:generic:level{1..3}:code

    A code or unique identifier for the top level of the financial source hierarchy

    • dataType: string
    • unique: True
    # fin-source:generic:level{1..3}:label

    Display name or title for the top level of the financial source hierarchy

    • dataType: string
    • labelOf: fin-source:generic:level1:code

    # Geographic Information

    # geo:generic:code

    Unique identifier or code for Geographic feature specified in the data

    • dataType: string
    • unique: True
    # geo:generic:codeList

    Indicates a specific code list from which a Geographic identifier is drawn

    • dataType: string
    • unique: True
    # geo:generic:title

    The display name of the geographic feature

    • dataType: string
    • labelOf: geo:generic:code
    # geo:source:code

    Unique identifier or code for Geographic feature specified in the data

    • dataType: string
    • unique: True
    # geo:source:codeList

    Indicates a specific code list from which a Geographic identifier is drawn

    • dataType: string
    • unique: True
    # geo:source:title

    The display name of the geographic feature

    • dataType: string
    • labelOf: geo:source:code
    # geo:target:code

    Unique identifier or code for Geographic feature specified in the data

    • dataType: string
    • unique: True
    # geo:target:codeList

    Indicates a specific code list from which a Geographic identifier is drawn

    • dataType: string
    • unique: True
    # geo:target:level{1..2}:code

    Unique identifier or code for the Top Level Geographic feature specified in the data

    • dataType: string
    • unique: True
    # geo:target:level{1..2}:title

    The display name for the Top Level Geographic feature specified in the data

    • dataType: string
    • labelOf: geo:target:level1:code
    # geo:target:title

    The display name of the geographic feature

    • dataType: string
    • labelOf: geo:target:code
    - + diff --git a/fiscal-data-package--spending/index.html b/fiscal-data-package--spending/index.html index 36a29794..f9a4ee76 100644 --- a/fiscal-data-package--spending/index.html +++ b/fiscal-data-package--spending/index.html @@ -8,7 +8,7 @@ - + @@ -86,6 +86,6 @@ Back to the main site (opens new window)

    WARNING

    This is a draft specification and still under development. If you have comments or suggestions please file them in the issue tracker (opens new window). If you have explicit changes please fork the git repo (opens new window) and submit a pull request.

    # Fiscal Data Package - Spending Standard Taxonomy

    The Budget Taxonomy is a set of ColumnTypes to be used in the context of a Fiscal Data Package to describe spending data of organizations (governments or otherwise.)

    Author(s)
    Created 14 March 2014
    Updated 22 April 2018
    JSON Schema fiscal-data-package-spending.json
    Version 1.0-rc.1

    # Language

    The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119

    # Changelog

    • 1.0.0rc1: Initial text

    # Introduction

    This document contains a ColumnType taxonomy to be used for publishing spending data files. It should be used in conjunction with the budget taxonomy, as it contains some common ColumnTypes as well.

    The ColumnTypes contained in this taxonomy contain:

    • Transactions Identifiers
    • Details about administrators, procurers, suppliers and recipients
    • Some Geographic related types (esp. for addresses)

    # References

    # Location

    The canonic location for this taxonomy’s ColumnType definition - to be used in fiscal data package descriptors - is

    https://specs.frictionlessdata.io/taxonomies/fiscal/spending.json

    # The Taxonomy

    # Amounts and their properties

    # Geographic Information

    # geo:address:city:code

    The code of the city part of the address

    • dataType: string
    • prior: geo:address:county:code
    • unique: True
    # geo:address:city:label

    The name of the city part of the address

    • dataType: string
    • labelOf: geo:address:city:code
    # geo:address:country:code

    The code of the country part of the address

    • dataType: string
    • unique: True
    # geo:address:country:label

    The name of the country part of the address

    • dataType: string
    • labelOf: geo:address:country:code
    # geo:address:county:code

    The code of the county part of the address

    • dataType: string
    • prior: geo:address:region:code
    • unique: True
    # geo:address:county:label

    The name of the county part of the address

    • dataType: string
    • labelOf: geo:address:county:code
    # geo:address:region:code

    The code of the region part of the address

    • dataType: string
    • prior: geo:address:country:code
    • unique: True
    # geo:address:region:label

    The name of the region part of the address

    • dataType: string
    • labelOf: geo:address:region:code
    # geo:address:street-address:description

    Actual street address in whole address

    • dataType: string
    # geo:address:zip:code

    The postal code in the address

    • dataType: string
    • prior: geo:address:city:code
    • unique: True

    # Actors involved in the Transaction (Administrator, Procurer)

    # administrator:generic:id

    Unique identifier for the Administrator

    • dataType: string
    • unique: True
    # administrator:generic:name

    The display name for the Administrator

    • dataType: string
    • labelOf: administrator:generic:id
    # procurer:bank:account

    Unique identifier for the bank account of the Procurer

    • dataType: string
    # procurer:bank:branch:code

    Unique identifier of the bank’s branch of the Procurer

    • dataType: string
    • unique: True
    # procurer:bank:branch:name

    Name of the bank’s branch of the Procurer

    • dataType: string
    • labelOf: procurer:bank:branch:code
    # procurer:bank:code

    Unique identifier for the bank of the Procurer

    • dataType: string
    • unique: True
    # procurer:generic:id

    Unique identifier for the Procurer

    • dataType: string
    • unique: True
    # procurer:generic:name

    The display name of the Procurer

    • dataType: string
    • labelOf: procurer:generic:id

    # Recipient of the Transaction

    # recipient:bank:account

    Unique identifier for the bank account of the Recipient

    • dataType: string
    # recipient:bank:branch:code

    Unique identifier of the bank’s branch of the Recipient

    • dataType: string
    • unique: True
    # recipient:bank:branch:name

    Name of the bank’s branch of the Recipient

    • dataType: string
    • labelOf: recipient:bank:branch:name
    # recipient:bank:code

    Unique identifier for the bank of the Recipient

    • dataType: string
    • unique: True
    # recipient:generic:id

    Unique identifier for the Recipient

    • dataType: string
    • unique: True

    Unique identifier for the codelist from which the legal entity code comes from

    • dataType: string
    • prior: recipient:generic:id
    • unique: True

    Unique identifier for the legal entity

    • dataType: string
    • prior: recipient:generic:legal-entity:code-type
    • unique: True

    Trading name (or other) of the legal entity

    • dataType: string
    • labelOf: recipient:generic:legal-entity:code

    Text describing the representative of the legal entity

    • dataType: string

    Code of the specific project inside the legal entity

    • dataType: string
    • prior: recipient:generic:legal-entity:code
    • unique: True

    Name of the specific project inside the legal entity

    • dataType: string

    Name of the specific project inside the legal entity

    • dataType: string
    • labelOf: recipient:generic:legal-entity:receiving-project:code

    Status of the specific project inside the legal entity

    • dataType: string
    # recipient:generic:name

    The display name for the Recipient

    • dataType: string
    • labelOf: recipient:generic:id
    # recipient:generic:url

    An Internet address for the Recipient

    • dataType: string

    # Supplier Details

    # supplier:generic:id

    Unique identifier for the Supplier

    • dataType: string
    • unique: True
    # supplier:generic:name

    The display name for the Supplier

    • dataType: string
    • labelOf: supplier:generic:id

    # Transaction Details

    # transaction-id:budget-code

    Unique identifier for the Budget Line for this transaction

    • dataType: string
    • unique: True
    # transaction-id:code

    A Unique identifier for this transaction

    • dataType: string
    • unique: True
    # transaction-id:contract-id

    Unique identifier for the Contract for this transaction

    • dataType: string
    • unique: True
    # transaction-id:court-order

    Unique identifier for the Court Order for this transaction

    • dataType: string
    • unique: True
    # transaction-id:invoice-id

    Unique identifier for the Invoice for this transaction

    • dataType: string
    • unique: True
    # transaction-id:purchase-order

    Unique identifier for the Purchase Order for this transaction

    • dataType: string
    • unique: True
    # transaction-id:tender-id

    Unique identifier for the Tender for this transaction

    • dataType: string
    • unique: True
    # transaction-id:tender-kind

    Unique identifier for the Tender Kind for this transaction

    • dataType: string
    # transaction-id:transaction-kind

    Unique identifier for the Transaction Kind for this transaction

    • dataType: string
    - + diff --git a/fiscal-data-package/index.html b/fiscal-data-package/index.html index 6eda329c..2a09d2dd 100644 --- a/fiscal-data-package/index.html +++ b/fiscal-data-package/index.html @@ -8,7 +8,7 @@ - + @@ -499,6 +499,6 @@
    Edit this page (opens new window)
    Last Updated: 5/28/2020, 10:00:53 AM
    - + diff --git a/guides/data-package/index.html b/guides/data-package/index.html index 5ae26b4c..8758e011 100644 --- a/guides/data-package/index.html +++ b/guides/data-package/index.html @@ -8,7 +8,7 @@ - + @@ -170,6 +170,6 @@ } }

    # Examples

    Many exemplar data packages can be found on datahub (opens new window). Specific examples:

    # World GDP

    A Data Package which includes the data locally in the repo (data is CSV).

    http://datahub.io/core/gdp (opens new window)

    Here’s the datapackage.json:

    https://pkgstore.datahub.io/core/gdp/9/datapackage.json (opens new window)

    # S&P 500 Companies Data

    This is an example with more than one resource in the data package.

    http://datahub.io/core/s-and-p-500-companies (opens new window)

    Here’s the datapackage.json:

    https://pkgstore.datahub.io/core/s-and-p-500-companies/10/datapackage.json (opens new window)

    # GeoJSON and TopoJSON

    You can see an example on how to package GeoJSON files here (opens new window).

    DataHub does not currently support the TopoJSON format. You can use “Vega Graph Spec” and display your TopoJSON data using the Vega specification (opens new window). See an example here (opens new window).

    - + diff --git a/guides/implementation/index.html b/guides/implementation/index.html index 6d788a83..05e810e9 100644 --- a/guides/implementation/index.html +++ b/guides/implementation/index.html @@ -8,7 +8,7 @@ - + @@ -85,6 +85,6 @@
    Back to the main site (opens new window)

    # Implementation

    This document is meant to serve as an introduction and an entry point into writing a library that implements a Frictionless Data specification. The focus is on two libraries in particular - Data Package and Table Schema - as implementing these libraries essentially implements the whole family of specifications.

    The reader, being an implementer/maintainer of such libraries, should get a clear understanding of the reference material available for undertaking work, and the minimal set of actions that such libraries must enable for their users.

    We prefer to focus on actions rather than features, feature sets, user stories, or more formal API specifications as we want to leave enough flexibility for implementations that follow the idioms of the host language, yet we do want to ensure a common base of what can be done with an implementation in any language.

    # Context

    While OKI and various other 3rd parties have been using the Data Package family of specifications with great success for several years, it has mostly been over the last 12 months that we are starting to see more mature libraries to implement the specifications at a “low level” for ease of reuse.

    At present, we consider the libraries maintained by Open Knowledge International in both Python and JavaScript to be reference implementations that serve as a guide for how to approach the specifications in code, and the type of actions that are enabled for users of the libraries. Further, we make extensive use of JSON Schema (opens new window) to validate descriptors that are passed to these libraries. This enables significant reuse across implementations for descriptor validation logic.

    # High-level requirements

    Here we will describe the minimal requirements for implementing Frictionless Data specifications in a given programming language. Based on the Python and JavaScript implementations, the implementations are split across two packages: Data Package and Table Schema.

    Also, see the stack reference (opens new window) section below for some naming conventions we use, and that ideally should be followed in new implementations.

    # Data Package library

    The Data Package library can load and validate any descriptor for a Data Package Profile, allow the creation and modification of descriptors, and expose methods for reading and streaming data in the package. When a descriptor is a Tabular Data Package, it uses the Table Schema library, and exposes its functionality, for each resource object in the resources array.

    # References

    # Actions

    • read an existing Data Package descriptor
    • validate an existing Data Package descriptor, including profile-specific validation via the registry of JSON Schemas
    • create a new Data Package descriptor
    • edit an existing Data Package descriptor
    • as part of editing a descriptor, helper methods to add and remove resources from the resources array
    • validate edits made to a data package descriptor
    • save a Data Package descriptor to a file path
    • zip a Data Package descriptor and its co-located references (more generically: “zip a data package”)
    • read a zip file that “claims” to be a data package
    • save a zipped Data Package to disk

    # Examples

    # Table Schema library

    The Table Schema library can load and validate any Table Schema descriptor, allow the creation and modification of descriptors, expose methods for reading and streaming data that conforms to a Table Schema via the Tabular Data Resource abstraction.

    # References

    # Actions

    • read an existing Table Schema descriptor
    • validate an existing Table Schema descriptor using the JSON Schema spec
    • create a new Table Schema descriptor
    • edit an existing Table Schema descriptor
    • provide a model-type interface to interact with a descriptor
    • infer a Table Schema descriptor from a supplied sample of data
    • validate a data source against the Table Schema descriptor, including in response to editing the descriptor
    • enable streaming and reading of a data source through a Table Schema (cast on iteration)

    # Examples

    # On dereferencing and descriptor validation

    Some properties in the Frictionless Data specifications allow a path (a URL or a POSIX path) that resolves to an object.

    The most prominent example of this is the schema property on Tabular Data Resource descriptors.

    Allowing such references has practical use for publishers, for example in allowing schema reuse. However, it does introduce difficulties in the validation of such properties. For example, validating a path pointing to a schema rather than the schema object itself will do little to guarantee the integrity of the schema definition. Therefore implementors MUST dereference such “referential” property values before attempting to validate a descriptor. At present, this requirement applies to the following properties in Tabular Data Package and Tabular Data Resource:

    • schema
    • dialect

    # Other libraries

    Data Package and Table Schema implement the core Frictionless Data specifications. The JavaScript implementations maintained by Open Knowledge International essentially follow the above requirements as is. However, our Python toolchain has some additional libraries - goodtables and tabulator - which are an important part of the Frictionless Data stack, and we would be delighted to see them implemented in other languages either as standalone libraries, or, as part of a wider effort in implementing Data Package and Table Schema.

    # tabulator

    tabulator provides a consistent interface for streaming reading and writing of tabular data. It supports CSV, which is required for Table Schema, Tabular Data Resource, and Tabular Data Package, and also supports Excel, JSON, newline delimited JSON, Google Sheets, and ODS.

    # References

    # goodtables

    goodtables validates tabular data, checking for structural and schematic errors, and producing reports that can be used to iterate on data file sources as part of common data publication work flows. goodtables uses tabulator, tableschema, and datapackage internally, as well as implementing data-quality-spec.

    It may be of general interest that goodtables is also available as a service - goodtables.io (opens new window) - providing continuous data validation in the style of CI solutions for code.

    # References

    # Work process

    Open Knowledge International coding standards can be found here (opens new window). While some of the standards document refers to idioms in JavaScript and Python, much of it is about more general standards around using git, testing requirements and so on. These need to be adhered to.

    We have some small example code repositories in Python and JavaScript that demonstrate these coding standards.

    If you would like to contribute sections based on idioms in your target language, that would be great: it will serve as a further reference to others, and also have the added benefit of enabling our team to learn from you.

    - + diff --git a/index.html b/index.html index 5b88194a..c41f087c 100644 --- a/index.html +++ b/index.html @@ -8,7 +8,7 @@ - + @@ -97,6 +97,6 @@ style tdp fill:#f9f,stroke:#333,stroke-width:4px;

    # Design Philosophy

    # Simplicity

    Seek zen-like simplicity in which there is nothing to add and nothing to take away.

    # Extensibility

    Design for extensibility and customisation. This makes hard things possible and permits future evolution – nothing we build will be perfect.

    # Human-editable and machine-usable

    Specs should preserve human readability and editability whilst making machine-use easy.

    # Reuse

    Reuse and build on existing standards and formats.

    # Cross technology

    Support a broad range of languages, technologies and infrastructures – avoid being tied to any one specific system.

    # Contribute

    Contributions, comments and corrections are warmly welcomed. Most work proceeds in an RFC-style manner with discussion in the issue tracker (opens new window).

    Material is kept in a git repo on GitHub (opens new window) - fork and submit a pull request to add material. There is also an issue tracker (opens new window) which can be used for specific issues or suggestions.

    # For Editors

    This repository is the canonical repository for the core Frictionless Data specifications. The repository features:

    • JSON Schema (opens new window) representations of all specifications. These are used both in the site itself, to generate the specification pages, and likewise in the schema registry that is used by a range of libraries that implement the specifications.

    # Quick start

    • Clone the repository
    • npm install # install the dependencies to build the specifications
    • npm run build # build the specifications
    • npm run test # test the specifications
    • npm start # start the local server

    # Contribute to the specifications

    All the source data for the specifications is in the /schemas directory. In there, you will find a .json file for each specification and a set of YAML files under /schemas/dictionary/*. There is a build.js script to build the specifications.

    • .json files are JSON Schemas for each spec, normalised using the $ref feature of JSON Schema. This normalisation ensures consistency in the way the specifications are written and validated, but is only used directly by the build.js script, which generated denormalised versions.
    • /build.js creates denormalised versions of each specification be dereferencing each $ref in the source schemas, and then saves these denormalised versions to /build/schemas directory.
    • /schemas/dictionary/* has all the property definitions for each specification. This is the place to add new properties or property collections, to edit contextual information and descriptive examples, and so on. See how this information is rendered in the macros template (opens new window).

    # Adding a new specification

    Yes we welcome and encourage additions to the registry! Any spec that is added must meet the following criteria:

    • Be related to the Data Packages family of specifications.
    • Have a publicly-accessible web page describing the specification.
    • Have a JSON Schema file that describes the specification.

    See the existing entries in the registry, and then take the following steps to add a new entry:

    1. Make a new pull request called registry/{NAME_OF_SPECIFICATION}
    2. The pull request features a JSON Schema file for the new specification, and adds the spec to registry.csv
    3. Write a brief description of the spec as part of the pull request.
    - + diff --git a/patterns/index.html b/patterns/index.html index 393de1d6..7fafff18 100644 --- a/patterns/index.html +++ b/patterns/index.html @@ -8,7 +8,7 @@ - + @@ -557,6 +557,6 @@ "missingValues": [ "tba", "" ] }

    …would be interpreted as…

    item description price
    1 Apple 0.99
    null Banana null
    3 null 1.20

    # Specification

    A field MAY have a missingValues property that MUST be an array where each entry is a string. If not specified, each field inherits from the values assigned to missingValues (opens new window) at the Tabular Data Resource level.

    # Implementations

    None known.

    - + diff --git a/profiles/index.html b/profiles/index.html index 7637dc52..59ab98f7 100644 --- a/profiles/index.html +++ b/profiles/index.html @@ -8,7 +8,7 @@ - + @@ -86,6 +86,6 @@ Back to the main site (opens new window)

    # Profiles

    Data Package and Data Resource Profiles

    Author(s) Paul Walsh, Rufus Pollock
    Created 11 December 2016
    Updated 24 May 2017
    JSON Schema profiles.json
    Version

    # Language

    The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119

    # Introduction

    Different kinds of data need different data and metadata formats. To support these different data and metadata formats we need to extend and specialise the generic Data Package. These specialized types of Data Package (or Data Resource) are termed profiles. For example, there is a Tabular Data Package profile that specializes Data Packages specifically for tabular data.

    Thus, every Package and Resource descriptor has a profile. The namespace for the profile is the type of descriptor, so the default profile, if none is declared, is data-package for a Package descriptor and data-resource for a Resource descriptor.

    In summary, an extension of Data Package may be formalised as a profile. A profile is a Data Package which extends the default specification towards more specific needs.

    # profile Property

    In addition to the concept, we need an explicit way for publishers to state the profile they are using and consumers to discover this.

    Thus, we have a profile property that declares the profile for the descriptor for this Package or Resource. For the default Data Package and Data Resource descriptor, this SHOULD be present with a value of data-package/data-resource, but if not, the absence of a profile is equivalent to setting "profile": "data-package"/ "profile": "data-resource".

    Custom profiles MUST have a profile property, where the value is a unique identifier for that profile. This unique identifier MUST be a string and can be in one of two forms. It can be an id from the official Data Package Schema Registry, or, a fully-qualified URL that points directly to a JSON Schema that can be used to validate the profile.

    As part of the Frictionless Data Specifications project, we publish a number of Data Package profiles such as:

    We also publish the following Data Resource profiles:

    - + diff --git a/security/index.html b/security/index.html index 014b35af..78c8b63a 100644 --- a/security/index.html +++ b/security/index.html @@ -8,7 +8,7 @@ - + @@ -142,6 +142,6 @@ 192.168.x.x range or the 10.100.x.x range. This would blunt mapping attacks against the internal network of your users
    but needs to be well thought out as even one omission could endanger network security

    Whitelist filters are much more secure as they allow the loading of Resources from a named list of domains only, but
    might be too restrictive for some uses.

    Edit this page (opens new window)
    Last Updated: 2/26/2020, 10:01:56 AM
    - + diff --git a/table-schema/index.html b/table-schema/index.html index 14f1cd65..4946d387 100644 --- a/table-schema/index.html +++ b/table-schema/index.html @@ -8,7 +8,7 @@ - + @@ -343,6 +343,6 @@ } ]

    Comment: Foreign Keys create links between one Table Schema and another Table Schema, and implicitly between the data tables described by those Table Schemas. If the foreign key is referring to another Table Schema how is that other Table Schema discovered? The answer is that a Table Schema will usually be embedded inside some larger descriptor for a dataset, in particular as the schema for a resource in the resources array of a Data Package (opens new window). It is the use of Table Schema in this way that permits a meaningful use of a non-empty resource property on the foreign key.

    Table Schema draws content and/or inspiration from, among others, the following specifications and implementations:

    - + diff --git a/tabular-data-package/index.html b/tabular-data-package/index.html index 529125fe..2285bd09 100644 --- a/tabular-data-package/index.html +++ b/tabular-data-package/index.html @@ -8,7 +8,7 @@ - + @@ -125,6 +125,6 @@ }
    - + diff --git a/tabular-data-resource/index.html b/tabular-data-resource/index.html index f11c09d2..26259000 100644 --- a/tabular-data-resource/index.html +++ b/tabular-data-resource/index.html @@ -8,7 +8,7 @@ - + @@ -186,6 +186,6 @@ { "A": 4, "B": 5, "C": 6 } ]
    - + diff --git a/tabular-diff/index.html b/tabular-diff/index.html index f813436f..adae5f5e 100644 --- a/tabular-diff/index.html +++ b/tabular-diff/index.html @@ -8,7 +8,7 @@ - + @@ -87,6 +87,6 @@ (opens new window)

    # Tabular Diff Format

    The Tabular Diff Format is a format for expressing the difference between two tables such that the difference is itself in tabular form.

    Author(s) Paul Fitzpatrick
    Created 16 December 2011
    Updated 27 May 2014
    JSON Schema
    Version 0.8.0

    # Language

    The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119

    # Summary

    The tabular diff format expresses the difference between two versions of a table.
    Here’s an example of a diff:

    @@bridgedesignerlength
    BrooklynJ. A. Roebling1595
    +++ManhattanG. Lindenthal1470
    ->WilliamsburgD. Duck->L. L. Buck1600
    QueensboroughPalmer & Hornbostel1182
    ............
    George WashingtonO. H. Ammann3500
    ---SpamspanS. Spamington10000

    As for text diffs, the format emphasizes significant changes. Also like text diffs, the format is unambiguous without color, but readily enhanced with it. Unlike text diffs, the format preserves the original tabular structure, allowing presentation with sensible visual alignment.

    There is a reference implementation of a tool for generating and processing tabular diffs at https://github.com/paulfitz/daff (opens new window).

    # Scope

    The tabular diff format can express the following kinds of changes in a table:

    • Inserted or deleted rows.
    • Inserted, deleted, or renamed columns.
    • Modified cell values.

    If the order of the rows or columns of the the table are meaningful, then the format can also express:

    • Reordered rows or columns.

    Changes in formatting and systematic transformation of data (such as capitalization) are not expressible.

    # General structure

    Assume we have two tables, called LOCAL and REMOTE. The diff summarizes the changes needed to modify LOCAL to match REMOTE.

    The diff contains rows and columns from the tables being compared. As in regular text diffs, there is flexibility in what data is given and what is omitted.

    • A column or row that is common to the tables being compared should appear at most once.
    • Any column or row containing a modified cell should be included in the diff, and the modified cell should be represented using the procedure in Expressing a modified cell value.
    • Columns or rows that are present in one table and not in the other should be included in the diff.
    • Columns or rows that are unchanged and unneeded for context may be omitted, at the diff creator’s discretion.
    • Omitted blocks of rows or columns should be marked with a row/column full of ... cells.

    In addition, the diff contains the following special rows and columns:

    • The action column. This is always present, and is the first column in the diff if columns are ordered. If columns are not ordered, it is the column named __hilite_diff__.
    • A header row with column names. This row can be recognized since it will have the tag @@ in the action column.
    • A schema row that is needed when the column structure differs between tables. This row can be recognized since it will have the tag ! in the action column.

    Here’s an example diff, where the tables being compared share the same three columns:

    action columndata from compared tables
    header row@@bridgedesignerlength
    BrooklynJ. A. Roebling1595
    +++ManhattanG. Lindenthal1470
    ->WilliamsburgD. Duck->L. L. Buck1600
    QueensboroughPalmer & Hornbostel1182
    omitted rows............
    George WashingtonO. H. Ammann3500
    ---SpamspanS. Spamington10000

    The colors do not make up part of this specification, they are just syntax highlighting. The meaning of the various tags will become clear in later sections, for now we are just concerned with the structure of the diff. Here’s an example where there is a difference in columns: LOCAL has a length column that is removed in REMOTE, REMOTE has an opened column that wasn’t present in LOCAL, and the designer column in LOCAL is renamed as lead designer in REMOTE:

    action columndata from compared tables
    schema row!+++(designer)---
    header row@@bridgeopenedlead designerlength
    +Brooklyn1883J. A. Roebling1595
    +Manhattan1909G. Lindenthal1470
    +Williamsburg1903L. L. Buck1600
    +Queensborough1909Palmer & Hornbostel1182
    +Triborough1936O. H. Ammann1380,383
    +Bronx Whitestone1939O. H. Ammann2300
    +Throgs Neck1961O. H. Ammann1800
    +George Washington1931O. H. Ammann3500

    We see that a schema row is added above the header row to represent the changes in columns. With this general anatomy of a diff in mind, let’s look at the details of how to interpret it.

    TIP

    If writing a rule to “sniff” a file to see if it is a tabular diff, the @@ tag is a handy tell-tale. But watch out for that schema row! Also, to allow for future evolution of this format, please try to be robust to a few extra rows or columns appearing before the @@.

    # Expressing inserted and deleted columns

    An inserted column is expressed simply by including that column in the diff, and placing +++ in the schema row above the corresponding column name in the header row. Similarly, a deleted column is expressed by including that column in the diff, and placing --- in the schema row above the corresponding column name. As a special case, a renamed column is represented by simply placing its old name in parentheses in the schema row.

    In our earlier example, LOCAL has the columns bridge, designer, and length, while REMOTE has the columns bridge, opened, and lead designer (designer renamed). So opened is inserted and length is deleted:

    action
    column    		data from compared tables
    schema row!+++(designer)---
    header row@@bridgeopenedlead designerlength
    +Brooklyn1883J. A. Roebling1595
    +Manhattan1909G. Lindenthal1470
    +Williamsburg1903L. L. Buck1600

    If we are dealing with a data store where columns are unordered, then likewise column order in the diff is irrelevant. Otherwise, the inserted and deleted rows should be placed in their appropriate order.

    Any rows in the diff that are present only the LOCAL table will leave inserted columns blank. Similarly, any rows in the diff that are present only in the REMOTE table will leave deleted columns blank. Rows that are present in both tables will have values in all cells.

    # Expressing inserted and deleted rows

    An inserted row is expressed simply by placing +++ in the action column, and placing cell values in the appropriate columns. If there are columns in the diff that are in LOCAL but not in REMOTE, these are left blank. Likewise, a deleted row is expressed by placing --- in the action column, and its cell values in the appropriate columns. If there are columns in the diff that are in REMOTE but not in LOCAL, these are left blank. For example, suppose in REMOTE there is a row about a New Bridge that wasn’t in LOCAL, and a row about a bridge called Spamspan has been dropped. Here is what the inserted and deleted rows would look like, lined up with the header row for reference:

    action
    column
    schema row!+++(designer)---
    header row@@bridgeopenedlead designerlength
     
    inserted row+++New Bridge2050Chimp N Zee   
     
    deleted row---SpamspanS. Spamington10000

    If the diff is on a database table where rows have no ordering, then we can just stick these rows together and we have our diff:

    action
    column
    schema row!+++(designer)---
    header row@@bridgeopenedlead designerlength
    inserted row+++New Bridge2050Chimp N Zee   
    deleted row---SpamspanS. Spamington10000

    If the diff is on a spreadsheet table or CSV file, we’d generally want to respect row ordering. In this case, we can add context rows around insertions so we know where to put them. Less importantly, since they are going away anyway, we can do the same for deletions:

    action
    column
    schema row!+++(designer)---
    header row@@bridgeopenedlead designerlength
    omitted rows...............
    context row+Williamsburg1903L. L. Buck1600
    inserted row+++New Bridge2050Chimp N Zee   
    context row+Queensborough1909Palmer & Hornbostel1182
    omitted rows...............
    context row+George Washington1931O. H. Ammann3500
    deleted row---SpamspanS. Spamington10000

    The action column for a context row may contain a blank, or :, or +. The : tag signifies the context row was moved (and its location is now as in the REMOTE table). The + signifies that there are cells added on that row.

    # Expressing a modified cell value

    If a row contains a cell whose value is different in the compared tables, then that row should be shown in the diff, with a tag in the action column that ends in ->. Then, the modified cell will be represented by converting the LOCAL and REMOTE values to text (we have yet to say how) and using the action tag as a separator. So for example here we change the last cell in a row from “Green” to “Blue”:

    ->GnomeHome and GardenGreen->Blue

    The tag must be preceded with as many extra - characters as are needed to avoid collision with any character sequence on that row. So here is another row with exactly one cell changed:

    -->ConsoleToddlers -> TeenagersWhite-->Pale

    When encoding a cell change as a string, we lose information about the type of the cell value. One distinction that may be important to retain is the difference between a NULL or empty cell, and the empty string. The tabular diff uses the following encoding:

    • A NULL value, if available, represents itself.
    • The encoded string NULL represents a NULL value.
    • The encoded string _NULL represents the string “NULL”.
    • The encoded string __NULL represents the string “_NULL”.
    • …

    The goal is that the diff can be safely converted to and from CSV by existing tools without changing its meaning. To that end:

    • For matching (e.g. on context lines) blank cells in the diff (either the NULL value or an empty string) should be treated as ambiguous, and match either of NULL or an empty string if an exact match is not available.
    • When using a diff as a patch, and inserting new cells, a blank cell in the diff (either the NULL value or an empty string) should be treated as ambiguous, and the “right” thing done given the column type. If either value could be inserted, then the blank string should be inserted (since the encoded string NULL is available to specifically identify the NULL value).

    Note that if the diff is being expressed in a table that allows nested structure (e.g. a JSON representation), a list representation for modified cells might be used to avoid this issue. There is no specification for that at this time.

    # Expressing a moved row

    TIP

    This can be ignored for tables for which row order is meaningless, e.g. in typical relational databases.

    A row that have been moved in a table for which row order is meaningful is marked with a : tag in the action column and placed in the order it appears in the REMOTE table.

    To avoid burdening human readers with too much arcana, tags are not combined when multiple kinds of actions apply to a row or column. So for example, a context row that was moved and had a cell added will not be tagged as :+ or +: or such-like, but rather by :. Cell addition can be determined from the schema row. These weak tags are included as aids for highlighting to express the most significant thing to know about a row.

    # Expressing a moved column

    TIP

    This can be ignored for tables for which column order is meaningless.

    A column that have been moved in a table for which column order is meaningful is marked with a : tag in the schema row and placed in the order it appears in the REMOTE table.

    If a diff that contains a : tag is used to patch a table for which column order is not meaningful, that tag should simply be ignored.

    # Reference: action column tags

    Symbol Meaning
    @@ The header row, giving column names.
    ! The schema row, given column differences.
    +++ An inserted row (present in REMOTE, not present in LOCAL).
    --- A deleted row (present in LOCAL, not present in REMOTE).
    -> A row with at least one cell modified cell. -->, --->, ----> etc. have the same meaning.
    Blank A blank string or NULL marks a row common to LOCAL and REMOTE, given for context.
    ... Declares that rows common to LOCAL and REMOTE are being skipped.
    + A row with at least one added cell.
    : A reordered row.

    # Reference: schema row tags

    Symbol Meaning
    +++ An inserted column (present in REMOTE, not present in LOCAL).
    --- A deleted column (present in LOCAL, not present in REMOTE).
    (<NAME>) A renamed column (the name in LOCAL is given in parenthesis, and the name in REMOTE will be in the header row).
    Blank A blank string or NULL marks a column common to LOCAL and REMOTE, given for context.
    ... Declares that columns common to LOCAL and REMOTE are being skipped.
    : A reordered column.
    - + diff --git a/views/index.html b/views/index.html index 0f774ea8..75ef5580 100644 --- a/views/index.html +++ b/views/index.html @@ -8,7 +8,7 @@ - + @@ -255,6 +255,6 @@ "specType": "table" }

    # Data Transforms

    In progress.

    - +