Justice League soundtrack is composed by Danny Elfman. The soundtrack was released on December 8, 2017 by WaterTower.
Justice league is a team of fictional superheroes appearing in American comic books. The comic books are published by DC comics.
To know more about Justice League, please click on the link beside Unite the league.


Akan names are derived from Ghanian culture.
Frequently in Ghana, children are given their first name as a 'day name'
which corresponds to the day in the week they were born. Here are
Ghanian day names.
To demonstrate how it works I have created a web application
that takes a user's birthday and calculates the day of the week
they were born and then depending on their gender outputs
their Akan Name.


--- layout: post title: Brighton Photo Fringe date: 2006-10-03 00:00:00 ---
Via Devi, an interesting event at Brighton Photo Fringe: "Timothy Prus... will be placing his own photographs upon a wall of the gallery and all are invited to swap up to three of their own photographs for the same number of Prus’s. This is an excellent way to not only own a fabulous piece of photography but also for your photograph to join his ever expanding archive alongside pictures from all over the world."


--- layout: post title: Using Capistrano to manage EC2 instances post_id: 98 categories: - redirect date: 2007-03-27 11:31:00.000000000 -06:00 author: Jamis permalink: 2007/3/27/using-capistrano-to-manage-ec2-instances.html ---
Jesse Newland announced the release of capazon today, a Capistrano extension library to manage Amazon EC2 instances. I love seeing the innovative ways that people are using Capistrano!
And, speaking of Capistrano, let me just say that I’m really, really excited about how Capistrano 2 is turning out… the code is all in the Rails repository, so brave souls may naturally follow along, but I hope to announce a beta gem in the not too distant future.


Pronounceable Passwords
Nothing is sent to the server. Everything runs client side.
Passwords:
Length:
Digits:
Clear
Generate


Top Tracks
Album
Artist
Tracks
Album
Artist
Alpha Music
Search
Drivers License
By: Olivia Rodrigo
Lyrics
Lyrics aren't attainable for this song
Album Pic
Release Date


--- layout: post title: "Full circle" subtitle: "New Zealand 2019" date: 2019-02-26 00:00:00 -0500 categories: [Travels] tags: [New Zealand] background: 'https://hwmckenzie.github.io/img/posts/nz2019/header.jpg' ---
Today we came back to the beginning. It took us 17 days to travel from Auckland to Christchurch by car, train, boat and foot. This morning we made the return trip by plane in 2 hrs. After dropping our bags at the very nice YMCA hotel, we headed out on foot to see the sights. First was a quick stop for lunch at a very tasty greek place that opened onto the street. We were in time to beat the lunchtime rush and were headed out on our afternoon adventure as the office workers were arriving. On the way to the waterfront we passed a park with uniformed school children playing (behaving in very un-uniform-suited ways!)
We walked to the waterfront and then along it as far as our feet would carry us. There was quite a lot of construction in the main part, and the buildings went right up to the water giving it a feeling of a very busy place indeed.
We even spotted some working dogs. After a bit of hovering with a professional sense of awe, Hannah asked if they were invasive species detection dogs, but they turned out to be explosives dogs. After we made our way out of the downtown core, we could see further into the harbour. Quite impressive! There were many sailboats at anchor and people sailing, surfing, and paddling along the edges of the main bay.
We stopped at the beach at Okahu Bay to sit and take stock. With a yen seeing more of the sights, we turned back towards downtown, caught a Lyft (before we wore our feet out entirely!) and headed for the Skytower.
The tower opened in 1997 and is 328 m high. It features such high flying adventures as the SkyWalk (where you walk around the tower on a walkway, tethered in) and the SkyJump (self explanatory!). In fact, as we arrived we saw someone base jump off the tower and come to a landing, assisted by a wire. Quite something! We purchased our tickets (sans SkyJump add-on!) and took the elevator up to the Main Observation deck located at level 51. The views were truly amazing!
It was quite neat to see where we had walked and to put it in perspective with the rest of the city. I experienced my own version of the SkyJump by inching my tipy-toes out over the glass floor. Oddly enough the knowledge that it was probably thicker than the solid floor I was standing on was not reassuring!
Chris was much more comfortable with the laws of physics and boldly stepped right on it!
We continued up to the Sky Deck at level 60 and the highest public observation deck, where the seamless glass almost made it feel like you were outside.
We had planned to splurge and dine at the Sugar Club, but they didn’t have any room, so we contented ourselves with a high altitude and very refreshing cider at the Sky Cafe.
After returning to the earth, we decided to start walking back to our hotel and seek out food along the way. Readers could probably guess that this has historically NOT been a good strategy for us (think hangry, yet picky and indecisive Hannah!). But on this night the stars aligned and we stumbled upon a very unique place. Through an unremarkable wooden door we found Elliot Stables, which claims to be, and indeed is, “an enchanting dinning village in the heart of the city, with twelve international eateries offering ethnic and local fare”. Not only did we get to eat tasty food in a wonderful ambience, and select exactly what we each wanted from different restaurants, but it was quite reasonably priced and fast! A real gem!
Appetites satisfied, we finished our walk home to enjoy our last sleep in NZ with our own private view of the Skytower.
Chris & Hannah


Type '!kmdtip help' for a list of actions. If you'd like to check your balance in private DM the bot and type "!kmdtip". Don't deposit too much.  A withdrawal fee of 0.02 KMD will be automatically deducted from the amount.Additionally, 10% of deducted withdrawal fee will be donated to the bot author to help continual development.
!kmdtip <@user> <amount|all> [private]
Tips the @ mentioned user with the desired amount, e.g.
!kmdtip @test123456#7890 1.00
!kmdtip rain <amount|all> [<@role>]
Rains the desired amount onto all online users (optionally, within specified role), e.g.
!kmdtip rain 10.00, !kmdtip rain 10.00 @Supporters
!kmdtip soak <amount|all> [<@role>]
Soaks the desired amount onto all online and idle users (optionally, within specified role), e.g.
!kmdtip soak 5.00, !kmdtip soak 5.00 @Supporters
!kmdtip thunder <amount|all> [<@role>]
Tips a random lucky online user with the amount (optionally, within specified role), e.g.
!kmdtip thunder 5.00, !kmdtip thunder 5.00 @Supporters
!kmdtip faucet
Gets an amount from the faucet (applicable every 4 hours)
!kmdtip listtransactions <numberOfDays>
Generates an audit log of user's transactions for the last specified number of days
Dr.Terminus21-Apr-19 12:11 PM
!kmdtip balance
KMD TipBotBOT21-Apr-19 12:11 PM
TipBot KMD Balance
Balance for @Dr.Terminus (Dr.Terminus#3269)
Confirmed
3.82465539
Unconfirmed
0.00000000
The Conqueror21-Apr-19 12:13 PM
!kmdtip balance
KMD TipBotBOT21-Apr-19 12:13 PM
TipBot KMD Balance
Balance for @The Conqueror (The Conqueror#4054)
Confirmed
1.46103518
Unconfirmed
0.00000000
The Conqueror21-Apr-19 12:13 PM
!kmdtip @⚔ bountyXhunter ⚔ 1.46103518
KMD TipBotBOT21-Apr-19 12:13 PM
TipBot
@The Conqueror (The Conqueror#4054)
You tipped @⚔ bountyXhunter ⚔1.46103518 KMD
phm8721-Apr-19 01:47 PM
!kmdtip balance
KMD TipBotBOT21-Apr-19 01:47 PM
TipBot KMD Balance
Balance for @phm87 (phm87 NN Candidate#7395)
Confirmed
0.75608993
Unconfirmed
0.00000000
deathsgrip21-Apr-19 02:23 PM
!kmdtip balance
KMD TipBotBOT21-Apr-19 02:23 PM
TipBot KMD Balance
Balance for @deathsgrip (deathsgrip#5269)
Confirmed
0.35160898
Unconfirmed
0.00000000
KS_AMS21-Apr-19 07:53 PM
!kmdtip
KMD TipBotBOT21-Apr-19 07:53 PM
TipBot Help
!kmdtip
Displays this message
!kmdtip info
Displays coin information
!kmdtip balance
Displays your balance
!kmdtip deposit [mobile]
Displays your deposit address, optionally formatted for mobile devices
!kmdtip withdraw <address> <amount|all>
Withdraws the entered amount to a KMD address of your choice, e.g.
!kmdtip withdraw GLM3n7yMFmYkas2AgHKqE6EMJW5VsUXtQn 5.20Note: Minimal amount to withdraw: 0.1 KMD. A withdrawal fee of 0.02 KMD will be automatically deducted from the amount.Additionally, 10% of deducted withdrawal fee will be donated to the bot author to help continual development.
!kmdtip <@user> <amount|all> [private]
Tips the @ mentioned user with the desired amount, e.g.
!kmdtip @test123456#7890 1.00
!kmdtip rain <amount|all> [<@role>]
Rains the desired amount onto all online users (optionally, within specified role), e.g.
!kmdtip rain 10.00, !kmdtip rain 10.00 @Supporters
!kmdtip soak <amount|all> [<@role>]
Soaks the desired amount onto all online and idle users (optionally, within specified role), e.g.
!kmdtip soak 5.00, !kmdtip soak 5.00 @Supporters
!kmdtip thunder <amount|all> [<@role>]
Tips a random lucky online user with the amount (optionally, within specified role), e.g.
!kmdtip thunder 5.00, !kmdtip thunder 5.00 @Supporters
!kmdtip faucet
Gets an amount from the faucet (applicable every 4 hours)
!kmdtip listtransactions <numberOfDays>
Generates an audit log of user's transactions for the last specified number of days
KS_AMS21-Apr-19 07:54 PM
!kmdtip info
KMD TipBotBOT21-Apr-19 07:54 PM
TipBot
Open-Source Infrastructure For An Interoperable Blockchain Ecosystem
We are building an ecosystem that empowers developers and businesses with end-to-end blockchain solutions with no limits.
@CrisF, check your direct messages for withdraw information.
  A withdrawal fee of 0.02 KMD will be automatically deducted from the amount.Additionally, 10% of deducted withdrawal fee will be donated to the bot author to help continual development.
!kmdtip <@user> <amount|all> [private]
Tips the @ mentioned user with the desired amount, e.g.
!kmdtip @test123456#7890 1.00
!kmdtip rain <amount|all> [<@role>]
Rains the desired amount onto all online users (optionally, within specified role), e.g.
!kmdtip rain 10.00, !kmdtip rain 10.00 @Supporters
!kmdtip soak <amount|all> [<@role>]
Soaks the desired amount onto all online and idle users (optionally, within specified role), e.g.
!kmdtip soak 5.00, !kmdtip soak 5.00 @Supporters
!kmdtip thunder <amount|all> [<@role>]
Tips a random lucky online user with the amount (optionally, within specified role), e.g.
!kmdtip thunder 5.00, !kmdtip thunder 5.00 @Supporters
!kmdtip faucet
Gets an amount from the faucet (applicable every 4 hours)
!kmdtip listtransactions <numberOfDays>
Generates an audit log of user's transactions for the last specified number of days
papawib26-Apr-19 04:38 AM
!kmdtip faucet
KMD TipBotBOT26-Apr-19 04:38 AM
TipBot
The faucet is not enabled.
papawib26-Apr-19 04:39 AM
!kmdtip info
KMD TipBotBOT26-Apr-19 04:39 AM
TipBot
Open-Source Infrastructure For An Interoperable Blockchain Ecosystem
We are building an ecosystem that empowers developers and businesses with end-to-end blockchain solutions with no limits.


Copyright © W3C 2014. This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.
Copyright © 2014 W3C.This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimersfor additional information.
Shape Expressions associate RDF graphs with labeled patterns called "shapes". Shapes can be used for validation, documentation and transformation of RDF data.
Shape Expressions express formal constraints on the content of RDF graphs and are intended to be used to validate RDF documents, communicate expected graph patterns for interfaces and to generate forms and validation code. This document describes the formal semantics of the Shape Expressions language through the use of the Z Specification Language. The accompanying Shape Expressions Primer provides an informal introduction to the language.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document describes the Shape Expressions langauge developed as a community effort. It is being submitted to W3C so that it can inform the development of a future RDF Data Shape specification.
By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.
The Shape Expressions Language (ShEx) is used to specify formal constraints on the content of RDF graphs and are intended to be used to validate RDF documents, communicate expected graph patterns for interfaces and to generate forms and validation code. ShEx can be used to:
Information about the use, grammar and syntax of ShEx can be found at http://www.w3.org/2013/ShEx. This document describes the formal semantics of the ShEx language using the Z specification language, beginning with a Z specification of the characteristics of an RDF Graph that are referenced by ShEx.
The formal definition for an RDF graph in RDF 1.1 Concepts and Abstract Syntax[RDF11-CONCEPTS]:
“An RDF graph is a set of RDF Triples”
“An RDF triple consists of three components:
- the subject, which is an IRI or a blank node
- the predicate, which is an IRI
- the object, which is an IRI, a literal or a blank node”
“... IRIs, literals and blank nodes are distinct and distinguishable.”
provides a definition in Z:
| [Graph, ℙ Triple] |
\begin{zed} Graph == \power Triple \end{zed}
The ShEx language treats IRIs and blank nodes as primitive types, which are defined as Z free types:
| [IRI, BlankNode] |
\begin{zed} [IRI, BlankNode] \end{zed}
The ShEx language can express constraints on both the type and content of literals, which are modeled separately:
“A literal in an RDF graph consists of two or three elements:
This is modelled by String and LanguageTag as free types:
| [String, LanguageTag] |
\begin{zed} [String, LanguageTag] \end{zed}and using them in the definition the two flavors of RDFLiteral, plain literal and typed literal::
| TypedLiteral ≙ [lexicalForm:String ; dataType : IRI] |
| PlainLiteral ≙ [lexicalForm:String ; langTag : String] |
| RDFLiteral ::= pl ⟨⟨PlainLiteral⟩⟩ | tl ⟨⟨TypedLiteral⟩⟩ |
\begin{zed} TypedLiteral \defs [lexicalForm:String ; dataType : IRI | dataType \neq XSD\_String] \\ PlainLiteral \defs [lexicalForm:String ; dataType : IRI; langTag : LanguageTag | \\ \t3 dataType = XSD\_String] \\ RDFLiteral ::= pl \ldata PlainLiteral \rdata | tl \ldata TypedLiteral \rdata \\ \end{zed}RDFTerm is defined as:
“IRIs, literals and blank nodes are collectively known as RDF terms
| RDFTerm ::= iri ⟨⟨IRI⟩⟩ | literal ⟨⟨RDFLiteral⟩⟩ | bnode ⟨⟨BlankNode⟩⟩ |
\begin{zed} RDFTerm ::= iri \ldata IRI \rdata | literal \ldata RDFLiteral \rdata | bnode \ldata BlankNode \rdata \end{zed}The definition of RDF Triple is modelled as a tuple consisting of three constrained RDFTerms:
| Triple | ||
| s, p, o : RDFTerm | ||
| iri ⋅ s ∈ IRI ∨ bnode ⋅ s ∈ BlankNode | ||
| iri ⋅ p ∈ IRI | ||
| iri ⋅ o ∈ IRI ∨ bnode ⋅ o ∈ BlankNode ∨ literal ⋅ o ∈ RDFLiteral | ||
\begin{schema}{Triple} s,p,o : RDFTerm \where iri \entryFor s \in IRI \lor bnode \entryFor s \in BlankNode \\ iri \entryFor p \in IRI \\ iri \entryFor o \in IRI \lor bnode \entryFor o \in BlankNode \lor literal \entryFor o \in RDFLiteral \end{schema}
The ShEx language uses the following functions:
– return set of triples in a graph triples whose subject is a given RDFTerm
| Triple | ||
| triplesForSubject : RDFTerm | ||
| ∀ subj : RDFTerm; g : Graph ∙ triplesForSubject subj g = {t : g | t.s = subj} | ||
\begin{gendef} triplesForSubject: RDFTerm \fun Graph \fun Graph \where \forall subj: RDFTerm; g: Graph @ triplesForSubject~subj~g = \{t: g | t.s = subj \} \end{gendef}
– return set of triples in a graph triples whose object is a given RDFTerm
| Triple | ||
| triplesForObject : RDFTerm | ||
| ∀ obj : RDFTerm; g : Graph ∙ triplesForObject obj g = {t : g | t.o = obj} | ||
\begin{gendef} triplesForObject: RDFTerm \fun Graph \fun Graph \where \forall obj: RDFTerm; g: Graph @ triplesForObject~obj~g = \{t: g | t.o = obj \} \end{gendef}
The following URI’s are referenced explicitly in the ShEx implementation:
| XSD_STRING, SHEX_IRI, SHEX_BNODE, SHEX_LITERAL, SHEX_NONLITERAL : IRI | ||
\begin{axdef} XSD\_STRING, SHEX\_IRI, SHEX\_BNODE, SHEX\_LITERAL, SHEX\_NONLITERAL : IRI \end{axdef}
The above definitions of Graph, Triple, RDFTerm and their components will now be used to describe the relationship between a ShEx Schema and an RDF graph.
A Shape Expression Schema is a collection of labeled rules where exactly one rule in the collection is identified as the outermost or “starting” rule. In addition, any rule that is referenced within the Schema is also itself a member of the Schema Formally:
| Schema | ||
| rules : Label ⇸ Rule | ||
| start : Label | ||
| start ∈ dom rules | ||
| ∀ r : ran rules ∙ | ||
| (r ∈ ran group ⇒ (group ⋅r).rule ∈ dom rules) ∧ | ||
| (r ∈ ran and ⇒ ran (and ⋅r) ⊆ dom rules) ∧ | ||
| (r ∈ ran xor ⇒ ran (xor ⋅r) ⊆ dom rules) ∧ | ||
| (r ∈ ran arc ∧ (arc ⋅r).valueSpec ∈ ran valueRef ⇒ | ||
| (valueRef ⋅(arc ⋅r).valueSpec) ∈ dom rules) | ||
\begin{schema}{Schema} rules : Label \pfun Rule \\ start : Label \where start \in \dom rules \\ \forall r: \ran rules @ \\ \t1 (r \in \ran group \implies (group \entryFor r).rule \in \dom rules) \land \\ \t1 (r \in \ran and \implies \ran (and \entryFor r) \subseteq \dom rules) \land \\ \t1 (r \in \ran xor \implies \ran (xor \entryFor r) \subseteq \dom rules) \land \\ \t1 (r \in \ran arc \land (arc \entryFor r).valueSpec \in \ran valueRef \implies \\ \t2 (valueRef \entryFor (arc \entryFor r).valueSpec) \in \dom rules) \end{schema}
While existing ShEx implementations define a rule Label as being either an IRI or a BlankNode, the type of Label does not impact the evaluation semantics. For our purposes, we can simply define it as a separate free type:
| [Label] |
\begin{zed} [Label] \end{zed}
The validity of a given RDF Graph is determined by taking the start Rule of a ShEx Schema and a reference IRI and evaluating the validity of the Rule against the supplied graph.
Formally, the evaluate function takes a Schema, a Graph and a reference IRI and, if the start Rule in the Schema, in the context of the starting Schema and graph, returns either nomatch (z) or pass (p) then the function returns pass. In all other cases, the function returns fail (f ).
| evaluate : Schema → Graph → IRI → OptValidity | ||
| ∀ s : Schema ; g : Graph ; i : IRI ; v : OptValidity ; ec : EvalContext | | ||
| ec.graph = g ∧ ec.schema = s ∙ | ||
| evaluatesgi = | ||
| if evalRule ec(iri i)(s.ruless.start) ∈ {z, p} | ||
| then p else f | ||
\begin{gendef} evaluate: Schema \fun Graph \fun IRI \fun OptValidity \where \forall s: Schema; g: Graph; i: IRI; v: OptValidity; ec: EvalContext | \\ \t1 ec.graph = g \land ec.schema = s @ \\ evaluate ~s ~g ~i = \\ \t1 \IF evalRule ~ec ~ (iri~ i)~ (s.rules~ s.start) \in \{\nomatch, \pass\} \\ \t1 \THEN \pass \ELSE \fail \end{gendef}
A ShEx Rule is a set of constraints that can be evaluated against a reference RDFTerm in the context of a given Schema and RDF Graph:
| EvalContext ≙ [schema : Schema ; graph : Graph] |
\begin{zed} EvalContext \defs [schema: Schema; graph: Graph] \\ \end{zed}
Formally, the evalRule function takes an EvalContext, a reference RDFTerm and a Rule and returns one of the following:
| OptValidity ::= p | f | z | ∅ | ε |
\begin{zed} OptValidity ::= \pass | \fail | \nomatch | \none | \error \\ \end{zed}A Rule can take one of five forms. Each will be formally described later in this document, but informally they are:
| Rule ::= arc⟨⟨ArcRule⟩⟩ | |
| rarc⟨⟨RevArcRule⟩⟩ | |
| group⟨⟨GroupRule⟩⟩ | |
| and⟨⟨AndRule⟩⟩ | |
| xor⟨⟨XorRule⟩⟩ |
\begin{zed} Rule ::= arc \ldata ArcRule \rdata | \\ \t1 rarc \ldata RevArcRule \rdata | \\ \t1 group \ldata GroupRule \rdata | \\ \t1 and \ldata AndRule \rdata | \\ \t1 xor \ldata XorRule \rdata \\ \end{zed}
| evalRule : EvalContext → RDFTerm → Rule → OptValidity | ||
| ∀ ec : EvalContext ; i : RDFTerm ; r : Rule ∙ evalRule ec i r = | ||
| if r ∈ ran arc | ||
| then evalArcRule ec i(arc ⋅ r) | ||
| else if r ∈ ran rarc | ||
| then evalRefArcRule ec i(arc ⋅ r) | ||
| else if r ∈ ran group | ||
| then evalGroupRule ec i(arc ⋅ r) | ||
| else if r ∈ ran and | ||
| then evalAndRule ec i(arc ⋅ r) | ||
| else | ||
| evalXorRule ec i(arc ⋅ r) | ||
\begin{gendef} evalRule: EvalContext \fun RDFTerm \fun Rule \fun OptValidity \where \forall ec: EvalContext; i:RDFTerm; r: Rule @ evalRule~ec~i~r = \\ \t1 \IF r \in \ran arc \\ \t2 \THEN evalArcRule~ec~i~(arc \entryFor r) \\ \t1 \ELSE \IF r \in \ran rarc \\ \t2 \THEN evalRevArcRule~ec~i~(rarc \entryFor r) \\ \t1 \ELSE \IF r \in \ran group \\ \t2 \THEN evalGroupRule~ec~i~(group \entryFor r) \\ \t1 \ELSE \IF r \in \ran and \\ \t2 \THEN evalAndRule~ec~i~(and \entryFor r) \\ \t1 \ELSE \\ \t2 evalXorRule~ec~i~(xor \entryFor r) \end{gendef}The evalRule′ function de-references the supplied Label and invokes evalRule with the result. This is not explicitly represented because the Z specification language does not allow cyclic dependencies. This function is undefined if Label is not in EvalContext
| evalRule′ : EvalContext → RDFTerm → Label → OptValidity | ||
| ∀ ec : EvalContext ; l : Label ∙ l ∈ dom ec.schema.shapes | ||
\begin{gendef} evalRule': EvalContext \fun RDFTerm \fun Label \fun OptValidity \where \forall ec: EvalContext; l:Label @ l \in \dom ec.schema.rules \end{gendef}
The ArcRule is used to select the subset of the graph having a given predicate or predicates and to determine whether the cardinality and/or “type” of this subset matches a supplied criteria. The rule itself consists of a PredicateFilter to select the triples, an ObjectSpecification to evaluate the result, an optional min and max cardinality and a (possibly empty) set of Actions:
| ArcRule | ||
| filter : PredicateFilter | ||
| valueSpec : ObjectSpecification | ||
| min, max : ℕ[0 ..1] | ||
| actions : ℙ Action | ||
| (#min = 1 ∧ #max = 1) ⇒ value min ≤ value max | ||
\begin{schema}{ArcRule} filter: PredicateFilter \\ valueSpec: ObjectSpecification \\ min, max: \optional[\nat] \\ actions: \power Action \where (\# min = 1 \land \# max = 1) \implies value~ min \leq value~ max \end{schema}ArcRule evaluation consists of:
| evalArcRule : EvalContext → RDFTerm → ArcRule → OptValidity | ||
| ∀ ec : EvalContext ; s : RDFTerm ; ar : ArcRule ; sg : Graph | | ||
| sg = evalPredicateFilter ar.filter (triplesForSubject s ec.graph) ∙ | ||
| evalArcRule ec s ar = | ||
| if evalCardinality sg ar.min ar.max ≠ p | ||
| then evalCardinality sg ar.min ar.max | ||
| else if evalObjectSpecification ec ar.valueSpec sg ≠ p | ||
| then evalObjectSpecification ec ar.valueSpec sg | ||
| else | ||
| dispatchar.actions sg ec | ||
\begin{gendef} evalArcRule: EvalContext \fun RDFTerm \fun ArcRule \fun OptValidity \where \forall ec: EvalContext; s: RDFTerm; ar: ArcRule; sg: Graph | \\ \t1 sg = evalPredicateFilter~ar.filter~(triplesForSubject~ s~ ec.graph) @ \\ evalArcRule~ec~s~ar = \\ \t1 \IF evalCardinality~sg~ar.min~ar.max \neq \pass \\ \t2 \THEN evalCardinality~sg~ar.min~ar.max \\ \t1 \ELSE \IF evalObjectSpecification~ec~ar.valueSpec~sg \neq \pass \\ \t2 \THEN evalObjectSpecification~ec~ar.valueSpec~sg \\ \t1 \ELSE \\ \t2 dispatch~ ar.actions~ sg~ ec \end{gendef}
A PredicateFilter can be one of:
| IRIorStem ::= iosi⟨⟨IRI⟩⟩ | ioss⟨⟨IRIstem⟩⟩ |
| PredicateFilter ::= pfIRI ⟨⟨IRIorStem⟩⟩ | pfWild ⟨⟨ℙ IRIorStem⟩⟩ |
\begin{zed} IRIorStem ::= iosi \ldata IRI \rdata | ioss \ldata IRIstem \rdata \\ PredicateFilter ::= pfIRI \ldata IRIorStem \rdata | pfWild \ldata \power IRIorStem \rdata \end{zed}An IRIstem matches any IRI whose stringified representation begins with the stringified representation of IRIstem according to standard IRI matching rules [RFC3987]. This is represented by the function:
| [IRIstem] |
\begin{zed} [IRIstem] \end{zed}
| IRIstemRange : IRIstem ⇸ ℙ IRI | ||
\begin{gendef} IRIstemRange: IRIstem \pfun \power IRI \end{gendef}evalPredicateFilter returns all of the triples in a Graph whose predicate matches the supplied PredicateFilter:
| evalPredicateFilter : PredicateFilter ⇸ Graph ⇸ Graph | ||
| ∀ f : PredicateFilter ; g : Graph ∙evalPredicateFilter f g = | ||
| if f ∈ ran pfIRI then evalIRIorStem(pfIRI ⋅ f) g | ||
| else evalWild(pfWild ⋅ f) g | ||
\begin{gendef} evalPredicateFilter : PredicateFilter \pfun Graph \pfun Graph \where \forall f: PredicateFilter; g: Graph @ evalPredicateFilter~ f ~g = \\ \t1 \IF f \in \ran pfIRI \THEN evalIRIorStem~ (pfIRI \entryFor f)~ g \\ \t1 \ELSE evalWild~ (pfWild \entryFor f)~ g \end{gendef}evalIRIorStem returns all of the triples in a Graph matching the supplied IRIorStem
| evalIRIorStem : IRIorStem ⇸ Graph ⇸ Graph | ||
| ∀ e : IRIorStem ; g : Graph ∙evalIRIorStem e g = | ||
| if e ∈ ran iosi then {t : g | iri ⋅ t.p = iosi ⋅ e} | ||
| else {t : g | iri ⋅ t.p ∈ IRIstemRange(iosi ⋅ e)} | ||
\begin{gendef} evalIRIorStem: IRIorStem \pfun Graph \pfun Graph \where \forall e: IRIorStem; g: Graph @ evalIRIorStem~ e ~g = \\ \t1 \IF e \in \ran iosi \THEN \{t : g | iri \entryFor t.p = iosi \entryFor e \} \\ \t1 \ELSE \{t: g | iri \entryFor t.p \in IRIstemRange~ (ioss \entryFor e) \} \end{gendef}evalWild returns all of the triples in a Graph that do not match an entry in the set of IRIorStems.
| evalWild : ℙ IRIorStem ⇸ Graph ⇸ Graph | ||
| ∀ es : ℙ IRIorStem ; g : Graph ∙evalWild es g = | ||
| {t : g | t ∉ ⋃ {e : es ∙ evalIRIorStemeg}} | ||
\begin{gendef} evalWild: \power IRIorStem \pfun Graph \pfun Graph \where \forall es: \power IRIorStem; g: Graph @ evalWild ~es ~g = \\ \t1 \{t: g | t \notin \bigcup \{e: es @ evalIRIorStem~e~g\} \} \end{gendef}
ObjectSpecification specifies a set of possible values for an RDFTerm and takes one of the following forms:
| MatchValue ::= mviri ⟨⟨IRI⟩⟩ | mviris ⟨⟨IRIstem⟩⟩ | |
| mvlit ⟨⟨RDFLiteral⟩⟩ |
| ObjectSpecification ::= valueType ⟨⟨IRI⟩⟩ | |
| valueSet ⟨⟨ℙ MatchValue⟩⟩ | |
| osWild ⟨⟨ℙ MatchValue⟩⟩ | |
| valueRef ⟨⟨Label⟩⟩ |
\begin{zed} MatchValue ::= mviri \ldata IRI \rdata | mviris \ldata IRIstem \rdata | \\ \t2 mvlit \ldata RDFLiteral \rdata \\ ObjectSpecification ::= valueType \ldata IRI \rdata | \\ \t1 valueSet \ldata \power MatchValue \rdata | \\ \t1 osWild \ldata \power MatchValue \rdata | \\ \t1 valueRef \ldata Label \rdata \end{zed}
– evaluates the cardinality the supplied graph.
| evalCardinality : Graph → ℕ[0..1] → ℕ[0..1] → OptValidity | ||
| ∀ g : Graph ; min , max : ℕ[0 ..1] ∙ evalCardinality g min max = | ||
| if #min = 1 ∧ #g = 0 ∧ value min = 0 | ||
| then z | ||
| else if #g = 0 | ||
| then ∅ | ||
| else if (#min = 1 ∧ #g < value min) ∨ | ||
| (#max = 1 ∧ #g > value max) | ||
| then f | ||
| else p | ||
\begin{gendef} evalCardinality: Graph \fun \optional[\nat] \fun \optional[\nat] \fun OptValidity \where \forall g: Graph; min, max: \optional[\nat] @ evalCardinality~g~min~max = \\ \t1 \IF \# min = 1 \land \# g = 0 \land value~ min = 0 \\ \t2 \THEN \nomatch \\ \t1 \ELSE \IF \# g = 0 \\ \t2 \THEN \none \\ \t1 \ELSE \IF (\# min = 1 \land \# g < value~ min) \lor \\ \t3 (\# max = 1 \land \# g > value~ max) \\ \t2 \THEN \fail \\ \t1 \ELSE \pass \end{gendef}
evalObjectSpecification – returns pass (p) if all of the triples in a Graph match the supplied ObjectSpecification, otherwise fail (f )
| evalObjectSpecification : EvalContext → ObjectSpecification → Graph → | ||
| OptValidity | ||
| ∀ ec : EvalContext ; os : ObjectSpecification ; g : Graph ∙ | ||
| evalObjectSpecification ec os g = | ||
| if ∀ t : g ∙ evalObjectSpecificationTriple ec os t.o = p then p | ||
| else f | ||
\begin{gendef} evalObjectSpecification: EvalContext \fun ObjectSpecification \fun Graph \fun \\ \t1 OptValidity \where \forall ec: EvalContext; os: ObjectSpecification; g: Graph @ \\ evalObjectSpecification~ec~os~g = \\ \t1 \IF \forall t: g @ evalObjectSpecificationTriple~ec~os~t.o = \pass \THEN \pass \\ \t1 \ELSE \fail \end{gendef}
| evalObjectSpecificationTriple : EvalContext → ObjectSpecification → | ||
| RDFTerm → OptValidity | ||
| ∀ ec : EvalContext ; os : ObjectSpecification ; n : RDFTerm ∙ | ||
| evalObjectSpecificationTriple ec os n = | ||
| if os ∈ ran valueType | ||
| then evalValueType (valueType ⋅ os) n | ||
| else if os ∈ ran valueSet | ||
| then evalTermSet (valueSet ⋅ os) n | ||
| else if os ∈ ran osWild | ||
| then evalTermWild (osWild ⋅ os) n | ||
| else | ||
| then evalReference ec (valueRef ⋅ os) n | ||
\begin{gendef} evalObjectSpecificationTriple: EvalContext \fun ObjectSpecification \fun \\ \t1 RDFTerm \fun OptValidity \where \forall ec:EvalContext; os: ObjectSpecification; n: RDFTerm @ \\ evalObjectSpecificationTriple~ec~os~n = \\ \t1 \IF os \in \ran valueType \THEN \\ \t2 evalValueType~(valueType \entryFor os)~n \\ \t1 \ELSE \IF os \in \ran valueSet \THEN \\ \t2 evalTermSet~(valueSet \entryFor os)~n \\ \t1 \ELSE \IF os \in \ran osWild \THEN \\ \t2 evalTermWild~(osWild \entryFor os)~n \\ \t1 \ELSE \\ \t2 evalTermReference~ec~(valueRef \entryFor os)~n \end{gendef}
evalValueType – returns pass if the supplied RDFTerm is:
| evalValueType : IRI ⇸ RDFTerm → OptValidity | ||
| ∀ vt : IRI ; n : RDFTerm ; l : RDFLiteral ∙ evalValueType vt n = | ||
| if vt = SHEX_IRI ∧ n ∈ ran iri then p | ||
| else if vt = SHEX_BNODE ∧ n ∈ ran bnode then p | ||
| else if vt = SHEX_NONLITERAL ∧ (n ∈ ran iri ∨ n ∈ ran bnode) then p | ||
| else if vt = SHEX_LITERAL ∧ n ∈ ran literal then p | ||
| else if n ∈ ran literal ∧ l = (literal ⋅ n) ∧ | ||
| ((l ∈ ran pl ∧ (pl ⋅ l). dataType = vt) ∨ | ||
| (l ∈ ran tl ∧ (tl ⋅ l). dataType = vt)) | ||
| then p | ||
| else f | ||
\begin{gendef} evalValueType: IRI \pfun RDFTerm \pfun OptValidity \where \forall vt: IRI; n: RDFTerm; l: RDFLiteral @ evalValueType~vt~ n = \\ \t1 \IF vt = SHEX\_IRI \land n \in \ran iri \THEN \pass \\ \t1 \ELSE \IF vt = SHEX\_BNODE \land n \in \ran bnode \THEN \pass \\ \t1 \ELSE \IF vt = SHEX\_NONLITERAL \land (n \in \ran iri \lor n \in \ran bnode) \THEN \pass \\ \t1 \ELSE \IF vt = SHEX\_LITERAL \land n \in \ran literal \THEN \pass \\ \t1 \ELSE \IF n \in \ran literal \land l = (literal \entryFor n) \land \\ \t2 ((l \in \ran pl \land (pl \entryFor l).dataType = vt) \lor \\ \t2 (l \in \ran tl \land (tl \entryFor l).dataType = vt)) \THEN \pass \\ \t1 \ELSE \fail \end{gendef}
evalTermSet – return p if the supplied RDFTerm is a member of MatchValue
| evalTermSet : ℙ MatchValue ⇸ RDFTerm ⇸ OptValidity | ||
| ∀ mvs : ℙ MatchValue ; n : RDFTerm ∙ evalTermSet mvs n = | ||
| if ∃ mv : mvs ∙ | ||
| ((mv ∈ ran mviri ∧ n ∈ ran iri ∧ (iri ⋅ n) = mviri ⋅ mv) ∨ | ||
| (mv ∈ ran mviris ∧ n ∈ ran iri ∧ | ||
| (iri ⋅ n) ∈ IRIstemRange (mviris ⋅ mv)) ∨ | ||
| (n ∈ ran literal ∧ mvlit ⋅ mv = literal ⋅ n)) | ||
| then p | ||
| else f | ||
\begin{gendef} evalTermSet: \power MatchValue \pfun RDFTerm \pfun OptValidity \where \forall mvs: \power MatchValue; n: RDFTerm @ evalTermSet~mvs~n = \\ \t1 \IF \exists mv: mvs @ \\ \t2 ((mv \in \ran mviri \land n \in \ran iri \land (iri \entryFor n) = mviri \entryFor mv) \lor \\ \t2 (mv \in \ran mviris \land n \in \ran iri \land \\ \t3 (iri \entryFor n) \in IRIstemRange ~ (mviris \entryFor mv) ) \lor \\ \t2 (n \in \ran literal \land mvlit \entryFor mv = literal \entryFor n)) \\ \t1 \THEN \pass \\ \t1 \ELSE \fail \end{gendef}
evalTermWild – return pass (p) if the supplied RDFTerm is not a member of MatchValue.
| evalTermWild : ℙ MatchValue → RDFTerm → OptValidity | ||
| ∀ mvs : ℙ MatchValue ; n : RDFTerm ∙ evalTermWild mvs n = | ||
| if evalTermSet mvs n = p then f else p | ||
\begin{gendef} evalTermWild: \power MatchValue \fun RDFTerm \fun OptValidity \where \forall mvs: \power MatchValue; n: RDFTerm @ evalTermWild~mvs~n = \\ \t1 \IF evalTermSet~ mvs~ n = \pass \THEN \fail \ELSE \pass \end{gendef}
evalTermReference – return p if the subgraph of the EvalContext graph whose subjects match the supplied RDFTerm satisfies the ValueReference rule.
| evalTermReference : EvalContext ⇸ Label ⇸ RDFTerm → OptValidity | ||
| ∀ ec : EvalContext ; vr : Label ; n : RDFTerm ∙ | ||
| evalTermReference ec vr n = | ||
| if n ∉ ran literal then evalRule′ ec n vr | ||
| else f | ||
\begin{gendef} evalTermReference: EvalContext \pfun Label \pfun RDFTerm \pfun OptValidity \where \forall ec: EvalContext; vr: Label; n: RDFTerm @ \\ evalTermReference~ec~vr~n = \\ \t1 \IF n \notin \ran literal \THEN evalRule'~ec~n~vr \\ \t1 \ELSE \fail \end{gendef}
The RevArcRule is used to select the subset of the graph having a given predicate or predicates and to determine whether the cardinality and/or “type” of this subset matches a supplied criteria. The rule itself consists of a PredicateFilter to select the triples, an SubjectSpecification to evaluate the result, a optional min and max cardinality and a (possibly empty) set of Actions:
| RevArcRule | ||
| filter : PredicateFilter | ||
| valueSpec : ObjectSpecification | ||
| min, max : ℕ[0 ..1] | ||
| actions : ℙ Action | ||
| (#min = 1 ∧ #max = 1) ⇒ value min ≤ value max | ||
\begin{schema}{RevArcRule} filter: PredicateFilter \\ valueSpec: SubjectSpecification \\ min, max: \optional[\nat] \\ actions: \power Action \where (\# min = 1 \land \# max = 1) \implies value~ min \leq value~ max \end{schema}RevArcRule evaluation consists of:
| evalRevArcRule : EvalContext → RDFTerm → RevArcRule → OptValidity | ||
| ∀ ec : EvalContext ; o : RDFTerm ; rar : RevArcRule ; og : Graph | | ||
| og = evalPredicateFilter rar.filter (triplesForObject o ec.graph) ∙ | ||
| evalArcRule ec o rar = | ||
| if evalCardinality og rar.min rar.max ≠ p | ||
| then evalCardinality og rar.min rar.max | ||
| else if evalObjectSpecification ec rar.valueSpec og ≠ p | ||
| then evalObjectSpecification ec rar.valueSpec og | ||
| else | ||
| dispatchar.actions og ec | ||
\begin{gendef} evalRevArcRule: EvalContext \fun RDFTerm \fun RevArcRule \fun OptValidity \where \forall ec: EvalContext; o: RDFTerm; rar: RevArcRule; og: Graph | \\ \t1 og = evalPredicateFilter~rar.filter~(triplesForObject~ o~ ec.graph) @ \\ evalRevArcRule~ec~o~rar = \\ \t1 \IF evalCardinality~og~rar.min~rar.max \neq \pass \\ \t2 \THEN evalCardinality~og~rar.min~rar.max \\ \t1 \ELSE \IF evalSubjectSpecification~ec~rar.valueSpec~og \neq \pass \\ \t2 \THEN evalSubjectSpecification~ec~rar.valueSpec~og \\ \t1 \ELSE \\ \t2 dispatch~ rar.actions~ og~ ec \end{gendef}
SubjectSpecification specifies a set of possible values for an RDFTerm and takes one of the following forms:
| SubjectSpecification ::= subjectSet⟨⟨ℙ MatchValue⟩⟩ | |
| ssWild ⟨⟨ℙ MatchValue⟩⟩ | |
| subjectRef ⟨⟨Label⟩⟩ |
\begin{zed} SubjectSpecification ::= subjectSet \ldata \power MatchValue \rdata | \\ \t1 ssWild \ldata \power MatchValue \rdata | \\ \t1 subjectRef \ldata Label \rdata \end{zed}
paragraphevalSubjectSpecification – returns pass (p) if all of the triples in a Graph match the supplied SubjectSpecification, otherwise fail (f )
| evalSubjectSpecification : EvalContext → SubjectSpecification → Graph → | ||
| OptValidity | ||
| ∀ ec : EvalContext ; o : Graph ; ss : SubjectSpecification ; g : Graph ∙ | ||
| evalSubjectSpecification ec ss g = | ||
| if ∀ t evalSubjectSpecificationTriple ec ss t.o = p then p | ||
| else f | ||
\begin{gendef} evalSubjectSpecification: EvalContext \fun SubjectSpecification \fun Graph \fun \\ \t1 OptValidity \where \forall ec: EvalContext; ss: SubjectSpecification; g: Graph @ \\ evalSubjectSpecification~ec~ss~g = \\ \t1 \IF \forall t: g @ evalSubjectSpecificationTriple~ec~ss~t.o = \pass \THEN \pass \\ \t1 \ELSE \fail \end{gendef}
| evalSubjectSpecificationTriple : EvalContext → SubjectSpecification → | ||
| RDFTerm → OptValidity | ||
| ∀ ec : EvalContext ; ss : SubjectSpecificationTriple ; n : RDFTerm ∙ | ||
| evalSubjectSpecificationTriple ec ss n = | ||
| if ss ∈ ran subjectSet | ||
| then evalTermSet(subjectSet ⋅ ss) n | ||
| else if ss ∈ ran ssWild | ||
| then evalTermWild(ssWild ⋅ ss) n | ||
| else | ||
| evalTermReferenceec(subjectRef ⋅ ss) n | ||
\begin{gendef} evalSubjectSpecificationTriple: EvalContext \fun SubjectSpecification \fun \\ \t1 RDFTerm \fun OptValidity \where \forall ec:EvalContext; ss: SubjectSpecification; n: RDFTerm @ \\ evalSubjectSpecificationTriple~ec~ss~n = \\ \t1 \IF ss \in \ran subjectSet \THEN \\ \t2 evalTermSet~(subjectSet \entryFor ss)~n \\ \t1 \ELSE \IF ss \in \ran ssWild \THEN \\ \t2 evalTermWild~(ssWild \entryFor ss)~n \\ \t1 \ELSE \\ \t2 evalTermReference~ec~(subjectRef \entryFor ss)~n \end{gendef}
A GroupRule serves two purposes. The first is to declare that a referenced rule is to be treated as “optional”, which, in this case means that if (a) the referenced rule returned none (∅), (meaning an ArcRule was encountered that had no matching predicates and a non-zero minimum cardinality) the group rule returns nomatch (z). An optional GroupRule also treats an error situation as a fail (f ).
The second purpose of a group rule is to allow a set of external actions to be evaluated whenever the referenced rule returns pass (p).
| OPT ::= OPTIONAL | REQUIRE |
| GroupRule ≙ [ rule : Label ; opt : OPT ; actions : ℙ Action ] |
\begin{zed} OPT ::= OPTIONAL | REQUIRED \\ GroupRule \defs [rule: Label; opt: OPT; actions: \power Action ] \\ \end{zed}evalGroupRule evaluates Rule, applies opt and, if the result is pass (p), evaluates the actions with respect to the passing Graph
| evalGroupRule : EvalContext → RDFTerm → GroupRule → OptValidity | ||
| ∀ ec : EvalContext ; i : RDFTerm ; gr : GroupRule ∙ evalGroupRule ec i gr = | ||
| if evalRule′ ec i gr.rule = ∅ ∧ gr.opt = OPTIONAL | ||
| then z | ||
| else if evalRule′ ec i gr.rule = ε ∧ gr.opt = OPTIONAL | ||
| then z | ||
| else if evalRule′ ec i gr.rule = p | ||
| then dispatch gr.actions ∅ ec | ||
| else | ||
| evalRule′ ec i gr.rule | ||
\begin{gendef} evalGroupRule: EvalContext \fun RDFTerm \fun GroupRule \fun OptValidity \where \forall ec: EvalContext; i: RDFTerm; gr: GroupRule @ evalGroupRule~ ec~ i ~ gr = \\ \t1 \IF evalRule'~ec~i~gr.rule = \none \land gr.opt = OPTIONAL \\ \t2 \THEN \nomatch \\ \t1 \ELSE \IF evalRule'~ec~i~gr.rule = \error \land gr.opt = OPTIONAL \\ \t2 \THEN \fail \\ \t1 \ELSE \IF evalRule'~ec~i~gr.rule = \pass \\ \t2 \THEN dispatch~ gr.actions~ \emptyset ~ ec \\ \t1 \ELSE evalRule'~ec~i~gr.rule \end{gendef}
An AndRule consists of a set of one or more Rules, whose evaluation is determined by
the following table:
| And | ∅ | z | f | p | ε |
| ∅ | ∅ | ∅ | f | f | ε |
| z | ∅ | z | f | p | ε |
| f | f | f | f | f | ε |
| p | f | p | f | p | ε |
| ε | ε | ε | ε | ε | ε |
| And | ∅ | z | f | p | ε |
|---|---|---|---|---|---|
| ∅ | ∅1 | ∅1 | f1 | f1 | ε1 |
| z | ∅1 | z1 | f1 | p1 | ε1 |
| f | f1 | f1 | f1 | f1 | ε1 |
| p | f1 | p1 | f1 | p1 | ε1 |
| ε | ε1 | ε1 | ε1 | ε1 | ε1 |
The formal implementation of which will be realized in the corresponding function:
| And : OptValidity → OptValidity → OptValidity | ||
\begin{gendef} And: OptValidity \fun OptValidity \fun OptValidity \end{gendef}
Observing that the above table is a monoid with nomatch (z) as an identity element, evalAndRule can be applied using the standard functional pattern:
| AndRule == seq₁ Label |
\begin{zed} AndRule == \seq_1 Label \end{zed}
| evalAndRule : EvalContext → RDFTerm → AndRule → OptValidity | ||
| ∀ ec : EvalContext ; i : RDFTerm ; r : AndRule ∙ | ||
| evalAndRule ec i r = | ||
| foldr And z (map (evalRule′ ec i) r) | ||
\begin{gendef} evalAndRule: EvalContext \fun RDFTerm \fun AndRule \fun OptValidity \where \forall ec: EvalContext; i: RDFTerm; r: AndRule @ \\ evalAndRule~ec~i~r = \\ \t1 foldr~ And~ \nomatch ~ (map~(evalRule'~ec~i)~r) \end{gendef}
An XorRule consists of a set of one or more Rules, whose evaluation is determined by
the following table:
| Xor | ∅ | z | f | p | ε |
| ∅ | ∅ | z | ∅ | p | ε |
| z | z | z | z | p | ε |
| f | ∅ | z | f | p | ε |
| p | p | p | p | ε | ε |
| ε | ε | ε | ε | ε | ε |
| Or | ∅ | z | f | p | ε |
|---|---|---|---|---|---|
| ∅ | ∅1 | z1 | ∅1 | p1 | ε1 |
| z | z1 | z1 | z1 | p1 | ε1 |
| f | ∅1 | z1 | f1 | p1 | ε1 |
| p | p1 | p1 | p1 | ε23 | ε1 |
| ε | ε1 | ε1 | ε1 | ε1 | ε1 |
| Xor : OptValidity → OptValidity → OptValidity | ||
\begin{gendef} Xor: OptValidity \fun OptValidity \fun OptValidity \end{gendef}As with the And function above, Xor is a monoid whose identity is fail (f ) resulting in the following definition for evalXorRule
| XorRule == seq₁ Label |
\begin{zed} XorRule == \seq_1 Label \end{zed}
| evalXorRule : EvalContext → RDFTerm → XorRule → OptValidity | ||
| ∀ ec : EvalContext ; i : RDFTerm ; r : XorRule ∙ | ||
| evalXorRule ec i r = | ||
| foldr Xor f (map (evalRule′ ec i) r) | ||
\begin{gendef} evalXorRule: EvalContext \fun RDFTerm \fun XorRule \fun OptValidity \where \forall ec: EvalContext; i: RDFTerm; r: XorRule @ \\ evalXorRule~ec~i~r = \\ \t1 foldr~ Xor~ \fail ~ (map~(evalRule'~ ec ~i)~ r) \end{gendef}
The dispatch function allows the evaluation / execution of arbitrary external “Actions”. While the evaluation of an Action can (obviously) have side effects outside the context of the ShEx environment, it must be side effect free within the execution context. In particular, an Action may not change anything in the EvalContext The action dispatcher exists to allow external events to happen. Parameters:
The dispatch function usually returns pass (p) or fail (f ), although there may also be cases for other OptValidity values in certain circumstances. The dispatch function always returns pass (p) if the set of actions is empty.
| [Action] |
\begin{zed} [Action] \end{zed}
| dispatch : ℙ Action → Graph → EvalContext → OptValidity | ||
| ∀ as : ℙ Action : g Graph : ec EvalContext ∙ | ||
| as = ∅ ⇒ dispatch as g ec = p | ||
\begin{gendef} dispatch: \power Action \fun Graph \fun EvalContext \fun OptValidity \where \forall as: \power Action; g: Graph; ec: EvalContext @ \\ \t1 as = \emptyset \implies dispatch~ as~ g ~ec = \pass \end{gendef}
The semantics of the productions and terminals from the Turtle specification are defined in Turtle Terse RDF Triple Language section 7 Parsing.
The following grammar rules are mapped to the abstract syntax:
Productions: | |||
| [1] | ShExDoc |
::= | statement* |
| [2] | statement |
::= | directive
| shape |
| [3] | directive |
::= | sparqlPrefix
| sparqlBase
| "start" "=" ( label | typeSpec CODE* ) let b = a fresh blank node typeSpec.setLabel(b) new ArcRule() |
| [4] | sparqlPrefix |
::= | SPARQL_PREFIX PNAME_NS IRIREF |
| [5] | sparqlBase |
::= | SPARQL_BASE IRIREF |
| [6] | shape |
::= | label typeSpec CODE* if (CODE.SIZE > 0) let r = new GroupRule(false, typeSpec) r.label = label else typeSpec.label = label |
| [7] | typeSpec |
::= | "{" OrExpression "}" |
| [8] | OrExpression |
::= | l:AndExpression ( "|" r:AndExpression )* if (r) new XorRule(l, r) else l |
| [9] | AndExpression |
::= | l:UnaryExpression ( "," r:UnaryExpression )* if (r) new AndRule(l, r) else l |
| [10] | UnaryExpression |
::= | arc |
| "(" OrExpression ")" opt:"?"? CODE* new GroupRule(OrExpression, opt, CODE) |
|||
| [11] | label |
::= | iri
| BlankNode |
| [12] | arc |
::= | nameClass valueSpec default? repeatCount? properties? CODE* new ArcRule(nameClass, valueSpec, default, repeatCount, properties, CODE) |
| [13] | nameClass |
::= | iriStem pfIRI(iriStem) |
| "." exclusions pfWild(exclusions) |
|||
| RDF_TYPE pfIRI(rdf:type) |
|||
| [14] | valueSpec |
::= | "@" label ValueReference(label) |
| typeSpec let b = a fresh blank node typeSpec.setLabel(b) |
|||
| valueSet new ValueSet(valueSet) |
|||
| object new ValueType(object) |
|||
| exclusions new ValueWild(exclusions) |
|||
| [15] | iriStem |
::= | iri ("~")? |
| [16] | default |
::= | "=" object |
| [17] | properties |
::= | "[" iri object ( ";" ( iri object )? )* "]" |
| [18] | exclusions |
::= | ( "-" iriStem )* |
| [19] | repeatCount |
::= | "*"
| "+"
| "?"
| "{" INTEGER ( "," (INTEGER)? )? "}" |
| [20] | valueSet |
::= | "(" (object)+ ")" |
| [21] | object |
::= | iriStem
| BlankNode
| literal |
| [22] | literal |
::= | RDFLiteral
| NumericLiteral
| BooleanLiteral |
| [23] | NumericLiteral |
::= | INTEGER
| DECIMAL
| DOUBLE |
| [24] | RDFLiteral |
::= | String ( LANGTAG | "^^" iri )? |
| [25] | BooleanLiteral |
::= | "true"
| "false" |
| [26] | String |
::= | STRING_LITERAL1
| STRING_LITERAL2
| STRING_LITERAL_LONG1
| STRING_LITERAL_LONG2 |
| [27] | iri |
::= | IRIREF
| PrefixedName |
| [28] | PrefixedName |
::= | PNAME_LN
| PNAME_NS |
| [29] | BlankNode |
::= | BLANK_NODE_LABEL
| ANON |
Terminals Not in Turtle: | |||
| [30] | <CODE > |
::= | "%" ( [a-zA-Z+#_] ([a-zA-Z0-9+#_])* )? "{" ( [^%\\] | "\\" "%" )* "%" "}" |
A Shape Expressions schema with no semantic actions can be treated as unordered. In practice, error messages can be much clearer, and extension functions much simpler to write if the engine follows the lexical order when validating the members of a conjunction. Likewise, form and interface code generation will be more predictable and controllable if the Shape Expressions are processed in a specific order.
The foldr function is the standard functional pattern, which takes a binary function of type T, an identity function for type T, a sequence of type T and returns the result of applying the function to the right to left pairs of the sequence.
\begin{gendef}[T] foldr: (T \fun T \fun T) \fun T \fun \seq T \fun T \where \forall f:T \fun T \fun T; id: T; xs: \seq T @ foldr~f~id~xs = \\ \t1 \IF xs = \langle \rangle \THEN id \\ \t1 \ELSE f~(head~xs)~(foldr~f~id~(tail~xs)) \end{gendef}
The map function takes a function from type A to type B and applies it to all members in the supplied sequence
| [A, B] | ||
| map : ( A → B ) → seq A → seq B | ||
| ∀ f : A → B ; xs : seq A ∙ map f xs = | ||
| if xs = ⟨⟩ then ⟨⟩⌢ | ||
| else ⟨f(head xs)⟩--map f(tail xs) | ||
\begin{gendef}[A,B] map: (A \fun B) \fun \seq A \fun \seq B \where \forall f: A \fun B; xs: \seq A @ map~f~xs = \\ \t1 \IF xs = \langle \rangle \THEN \langle \rangle \\ \t1 \ELSE \langle f~(head~xs) \rangle \cat map~f~(tail~xs) \end{gendef}
Z uses the notion of free type definitions in the form:
| FreeType ::= constructor⟨⟨source⟩⟩ |
\begin{syntax} FreeType ::= constructor \ldata source \rdata \end{syntax}which introduces a collection of constants of type FreeType, one for each element of the set source. constructor is an injective function from source to FreeType:
| constructor ::= source ↣ FreeType |
\begin{syntax} constructor ::= source \inj FreeType \end{syntax}In the models that follow, there is a need to reverse this – to find the source for a given FreeType instance. The ⋅ function exists for this purpose. As an example, if one were to define:
| TravelDirections ::= bus⟨⟨BusDirections⟩⟩ | walking⟨⟨WalkingDirections⟩⟩ |
\begin{syntax} TravelDirections ::= bus \ldata BusDirections \rdata | \ walking \ldata WalkingDirections \rdata \end{syntax}If one is supplied with an instance of Travel , one can convert it to the appropriate type by:
| x : TravelDirections | ||
| if x ∈ ran bus then bus ⋅ x else walking ⋅ x |
\begin{syntax} x : TravelDirections \where \IF x \in \ran bus \THEN bus \entryFor x \ELSE walking \entryFor x \end{syntax}
| [X, Y] | ||
| _⋅_: (X ↣ Y) × Y ⇸ X | ||
| ∀ y : Y; f : X ↣ Y ∙ f⋅y = (μx : dom f | f x = y) | ||
\begin{gendef}[X, Y] \_~ \entryFor \_~ : (X \inj Y) \cross Y \pfun X % \where % \forall y : Y; f : X \inj Y @ f \entryFor y = (\mu x : \dom f | f~x = y) \end{gendef}
One way to represent optional values is a set with one member. We take that route here and introduce a bit of syntactic sugar to show our intent:
| T[0..1] == {s : ℙ T | #s ≤ 1} |
\begin{zed} \optional[T] == \{ s : \power T \mid \# s \leq 1 \} \\ \end{zed}
And a shorthand for addressing the content:
| [T] | ||
| value: ℙ T ⇸ T | ||
| ∀ s : ℙ T ∙ value s = (μ e : T | e ∈ s) | ||
\begin{gendef}[T] value: \power T \pfun T \where \forall s: \power T @ value~ s = (\mu e : T | e \in s) \end{gendef}


Jaiffa (Javascript Interactive Fiction/Adventures) is a toy library for the creation of text adventures that can be embedded in a Web page. It was created as a programming exercise and idea testbed. Jaiffa is small, fast, and easy to use, study or modify.
Jaiffa provides a DSL (Domain Specific Language) for the creation of text adventures, but the user interface needs to be implemented separately. The demo adventure comes with example code.
Jaiffa is not meant for real-world usage. If you want to write serious interactive fiction, I urge you to consider one of the mainstream authoring systems. Jaiffa is kept deliberately simplistic; any game made with it would be far from meeting the expectations of a modern player. Also, due to the syntax of Javascript, writing long messages is difficult.
Jaiffa borrows what I consider to be some good simplifying ideas from MU*s.
Some additions of my own:
Jaiffa works in Firefox 3.5, Opera 10, Arora 0.10 (Webkit-based), and partially in Konqueror 4 and Nokia Browser.
Right now the parser is restricted to two-word commands. It's plenty enough to implement a complete, if primitive, adventure. But I'd like a future version to be smarter.
No save, load or undo yet. To restart, just reload the Web page.
No light sources either; for now, just flip the dark flag on rooms manually.
The library messages should be gathered in one place for easy translation.
To the game


HOUSED WORKS IN FOUR SIMPLES STEPS.
1- SEARCH
It's simple. On Housed homepage, you are able to look for a house to rent by writting the region, or country.
2- LOCATE
Write in the search bar the location that you are looking for and take a look at the options.
3- APPLY
Fill the form to request for the house that you would like to rent or buy, so you enter in to the selection process.
4- MOVE
Once you got the house just left the move! Congrats.
Over 10.000 houses in our web
Find a house using our filter
Houses from all the prices.
Don't hesistate in take a look
Anytime Anywhere Any way
Very convenient platform that cut across any device including our mobile ready web app and our mobile app coming soon to your app store.


Weekly musing #3 - Mr Bitcoin is hungry
Bitcoin Unlimited
I raised BUIP051, am going to take a close look at porting those changes over from XT during the coming week or two.
Happily, the proposal to spend some money for a better (paid) Travis build service has met with a supportive reception at BU, so I think we are soon going to have the possibility to run longer test suites (up to 120 minutes each - maybe need to break the test suite down into several batches which individually fit in under 2 hrs, or just execute randomly and time out just below 2 hrs).
Parallel execution of regression tests might be helpful. I'm planning to add that feature to BU's rpc-tests.py (Core has had that feature for a while).
Until then, I've pull-requested some minor test runner improvements I made in MVF-BU, to allow execution of single tests with specific arguments, and allow one-off test runs of disabled tests. This should make it a little easier for testers to run disabled tests - now they don't have to edit the rpc-tests.py script code to temporarily enable a test.
Some nice changes from Classic have been ported to BU by kyuupichan: the improved command line parameter handling which prevents invalid parameters from being silently ignored at startup.
BTCfork
Finally got around to merging the latest Bitcoin Unlimited dev branch changes back into MVF-BU. Turned out to be something like 1200+ commits - who said BU isn't developmentally active?
Unfortunately, Travis is not yet completely happy with my merge - it seems some build environment changes or file movements have broken the test framework. My own 32-bit test system also needs to upgrade to a C++11 compiler to handle the upstream compiler requirement changes. All in all, these seems like minor things that can be cleaned up fairly quickly - over the course of the next few days. After that, MVF-BU will be back on track for further development.
Extension blocks or bigger regular blocks
After Gregory Maxwell's recent post on bitcoin-dev, the clamor for UASF SegWit seems to have died down a bit - maybe it's just on the back burner.
Bitcoin Unlimited seems to be within good reach of regular big blocks.
Extension Blocks looks like another promising idea, but quite a complex undertaking in comparison to straightforward big blocks.
Maybe Mr Bitcoin will place an order for both, and see which one the kitchen can deliver first?
Footnotes
[1] Original Japanese Silky Tofu image by DryPot (CC-BY-SA-3.0) at
https://en.wikipedia.org/wiki/Tofu#/media/File:Japanese_SilkyTofu_%28Kinugoshi_Tofu%29.JPG>


software engineer researcher Kolabri DATEV InnerSource Commons InnerSource open source transfer pricing for InnerSource software dev. analytics
Find out more about me on Github, StackOverflow, Google Scholar, LinkedIn, XING, or via an email to<EMAIL_ADDRESS>| Treidler, O., Kunz, T.-E., Capraro, M., Dorner, M. (2022). Sustaining Arm’s Length Cost Allocations for Highly Integrated Development Functions – an Explorative Case Study of Transfer Pricing for InnerSource Communities. MNETAX. | [Link] |
| Stol, K.-J., Coffey, C., Dillon, C., Spier, S., Capraro, M., Izquierdo Cortazar, D. (2022). State of InnerSource 2021. Report by the InnerSource Commons Foundation, Delaware, US. | [Link] |
| Capraro, M. (2020, June). Measuring Inner Source Collaboration. Dissertation at the Friedrich-Alexander-University Erlangen-Nürnberg, Germany. | [PDF] |
| Kirsch, C., Drost-Fromm, I., Tigges, J., Dorner, M., & Capraro, M. (2019, July). Inner Source: Open-Source-Prinzipien im Unternehmen anwenden. In iX - Magazin für professionelle Informationstechnik. Heise Verlag. | [Link] |
| Capraro, M., Dorner, M., & Riehle, D. (2018, May). The Patch-Flow Method for Measuring Inner Source Collaboration. In 2018 IEEE/ACM 15th International Conference on Mining Software Repositories (MSR) (pp. 515-525). IEEE. | [PDF] |
| Capraro, M., & Riehle, D. (2017). Inner Source Definition, Benefits, and Challenges. ACM Computing Surveys (CSUR), 49(4), 67. | [PDF] |
| Riehle, D., Capraro, M., Kips, D., & Horn, L. (2016). Inner Source in Platform-Based Product Engineering. IEEE Transactions on Software Engineering, 42(12), 1162-1177. | [PDF] |
| Capraro, M. (2013). Towards a Representative and Diverse Analysis of Issue-Tracker Related Code and Process Metrics. Master Thesis at Friedrich-Alexander-University Erlangen-Nürnberg, Germany. | [PDF] |
Also, I had the privilege to supervise 15 student theses and other projects on inner source, open source, and software development. You can find some of them here.


Ant Task¶
Initiate CookCC Ant Task¶
To use CookCC Ant Task, first add the following line (and modify the
class path) to your build.xml
so that Ant recognizes <cookcc>
.
<target name="initcookcc">
<taskdef name="cookcc" classname="org.yuanheng.cookcc.ant.Task" classpath="${basedir}/tool/cookcc-0.3.jar"/>
</target>
Generic CookCC Input¶
For input files such as *.xcc
, the typical setup is.
<target name="TokenParser.java" depends="initcookcc">
<cookcc src="${basedir}/src/org/yuanheng/cookcc/util/TokenParser.xcc">
<option name="-class" value="org.yuanheng.cookcc.util.TokenParser"/>
<option name="-d" value="${basedir}/src"/>
</cookcc>
</target>
The attributes of <cookcc>
are the following:
| Attribute | Description |
|---|---|
| src | the input file. |
| lang | Same as -lang command line option. Select the
output language. The default is java |
| analysis | Same as -analysis command line option. |
| lexertable | Same as -lexertable command line option. |
| parsertable | Same as -parsertable command line option. |
| defaultreduce | Same as -defaultreduce command line option. |
Additional language specific options can be specified using the nested
<option>
tag.
Annotation Processing Tool (APT)¶
If the input file specified in the src
attribute has the .java
extension, APT mode is assumed.
The annotation processing API changed from 1.5 to 1.6+. As the result CookCC 0.3.3 only supports JDK1.5 and 1.6, while CookCC 0.4.0 and later supports JDK1.6+.
The typical setup is the following.
<target name="FileHeaderLexer.java" depends="initcookcc">
<cookcc srcdir="${basedir}/javaap_src" src="org/yuanheng/cookcc/input/javaap/FileHeaderScanner.java"/>
</target>
| Attribute | Description |
|---|---|
| srcdir | the source directory. It is required. |
| destdir | the output directory. If not specified, it would be
the same as srcdir . |
| src | a list of java files separated by space. Note that
the path is relative to the directory specified by
srcdir attribute. |
| lang | Same as -lang command line option. Select the
output language. The default is java |
| analysis | Same as -analysis command line option. |
| lexertable | Same as -lexertable command line option. |
| parsertable | Same as -parsertable command line option. |
| defaultreduce | Same as -defaultreduce command line option. |
Additional language specific options can be specified using the nested
<option>
tag.
Nested Option Tag¶
<option>
is used to specify additional language specific command
line options. It has two attributes.
| Attribute | Description |
|---|---|
| name | the option name, such as -class , -d etc |
| value | the option value. It is optional. |


piXedfit_bin¶
-
piXedfit.piXedfit_bin.
pixel_binning
(fits_fluxmap, ref_band=None, Dmin_bin=4.0, SNR=None, redc_chi2_limit=4.0, del_r=2.0, name_out_fits=None)¶ Function for pixel binning, a proses of combining neighboring pixels to optimize the signal-to-noise ratios of the spatially resolved SEDs. Input of this function is a data cube obtained from the image processing or spectrophotometric processing.
Parameters: - fits_fluxmap – Input FITS file containing the photometric or spectrophotometric data cube. The photometric data cube is obtained from the image processing with the
images_processing()
function, while the spectrophotmetric data cube is the output of functionmatch_imgifs_spectral()
. - ref_band – Index of the reference band (filter) for sorting pixels based on the brightness. The central pixel of a bin is the brightest pixel in this reference band. If ref_band=None, the ref_band is chosen to be around the middle of the wavelength covered by the observed SEDs.
- Dmin_bin – Minimum diameter of a bin in unit of pixel.
- SNR – S/N thresholds in all bands. The length of this array should be the same as the number of bands in the fits_fluxmap. S/N threshold can vary across the filters. If SNR is None, the S/N is set as 5.0 to all the filters.
- redc_chi2_limit – A maximum reduced chi-square value for a pair of two SEDs to be considered as having a similar shape.
- del_r – Increment of circular radius (in unit of pixel) adopted in the pixel binning process.
- name_out_fits – Desired name for the output FITS file. If None, a default name is adopted.
- fits_fluxmap – Input FITS file containing the photometric or spectrophotometric data cube. The photometric data cube is obtained from the image processing with the
-
piXedfit.piXedfit_bin.
pixel_binning_images
(images, var_images, ref_band=None, Dmin_bin=2.0, SNR=None, redc_chi2_limit=4.0, del_r=2.0, name_out_fits=None)¶ Function for pixel binning on multiband image.
Parameters: - images – Input science images. This input should be in a list format, such as images=[‘image1.fits’, ‘image2.fits’, ‘image3.fits’]
- var_images – Variance images in a list format. The number of variance images should be the same as that of the input science images.
- ref_band – Index of the reference band (filter) for sorting pixels based on the brightness. The central pixel of a bin is the brightest pixel in this reference band. If ref_band=None, the ref_band is chosen to be around the middle of the wavelength covered by the observed SEDs.
- Dmin_bin – Minimum diameter of a bin in unit of pixel.
- SNR – S/N thresholds in all bands. The length of this array should be the same as the number of bands in the fits_fluxmap. S/N threshold can vary across the filters. If SNR is None, the S/N is set as 5.0 to all the filters.
- redc_chi2_limit – A maximum reduced chi-square value for a pair of two SEDs to be considered as having a similar shape.
- del_r – Increment of circular radius (in unit of pixel) adopted in the pixel binning process.
- name_out_fits – Desired name for the output FITS file. If None, a default name is adopted.


Container¶
Container Auditor¶
-
class
swift.container.auditor.
ContainerAuditor
(conf, logger=None)¶ Bases:
swift.common.daemon.Daemon
Audit containers.
-
container_audit
(path)¶ Audits the given container path
Parameters: path – the path to a container db
-
run_forever
(*args, **kwargs)¶ Run the container audit until stopped.
-
run_once
(*args, **kwargs)¶ Run the container audit once.
-
-
swift.container.auditor.
random
() → x in the interval [0, 1).¶
Container Backend¶
Pluggable Back-ends for Container Server
-
class
swift.container.backend.
ContainerBroker
(db_file, timeout=25, logger=None, account=None, container=None, pending_timeout=None, stale_reads_ok=False)¶ Bases:
swift.common.db.DatabaseBroker
Encapsulates working with a container database.
-
create_container_info_table
(conn, put_timestamp, storage_policy_index)¶ Create the container_info table which is specific to the container DB. Not a part of Pluggable Back-ends, internal to the baseline code. Also creates the container_stat view.
Parameters: - conn – DB connection object
- put_timestamp – put timestamp
- storage_policy_index – storage policy index
-
create_object_table
(conn)¶ Create the object table which is specific to the container DB. Not a part of Pluggable Back-ends, internal to the baseline code.
Parameters: conn – DB connection object
-
create_policy_stat_table
(conn, storage_policy_index=0)¶ Create policy_stat table.
Parameters: - conn – DB connection object
- storage_policy_index – the policy_index the container is being created with
-
db_contains_type
= 'object'¶
-
db_reclaim_timestamp
= 'created_at'¶
-
db_type
= 'container'¶
-
delete_object
(name, timestamp, storage_policy_index=0)¶ Mark an object deleted.
Parameters: - name – object name to be deleted
- timestamp – timestamp when the object was marked as deleted
- storage_policy_index – the storage policy index for the object
-
empty
()¶ Check if container DB is empty.
Returns: True if the database has no active objects, False otherwise
-
get_db_version
(conn)¶
-
get_info
()¶ Get global data for the container.
Returns: dict with keys: account, container, created_at, put_timestamp, delete_timestamp, status_changed_at, object_count, bytes_used, reported_put_timestamp, reported_delete_timestamp, reported_object_count, reported_bytes_used, hash, id, x_container_sync_point1, x_container_sync_point2, and storage_policy_index.
-
get_info_is_deleted
()¶ Get the is_deleted status and info for the container.
Returns: a tuple, in the form (info, is_deleted) info is a dict as returned by get_info and is_deleted is a boolean.
-
get_misplaced_since
(start, count)¶ Get a list of objects which are in a storage policy different from the container’s storage policy.
Parameters: - start – last reconciler sync point
- count – maximum number of entries to get
Returns: list of dicts with keys: name, created_at, size, content_type, etag, storage_policy_index
-
get_policy_stats
()¶
-
get_reconciler_sync
()¶
-
has_multiple_policies
()¶
-
list_objects_iter
(limit, marker, end_marker, prefix, delimiter, path=None, storage_policy_index=0, reverse=False)¶ Get a list of objects sorted by name starting at marker onward, up to limit entries. Entries will begin with the prefix and will not have the delimiter after the prefix.
Parameters: - limit – maximum number of entries to get
- marker – marker query
- end_marker – end marker query
- prefix – prefix query
- delimiter – delimiter for query
- path – if defined, will set the prefix and delimiter based on the path
- storage_policy_index – storage policy index for query
- reverse – reverse the result order.
Returns: list of tuples of (name, created_at, size, content_type, etag)
-
make_tuple_for_pickle
(record)¶
-
merge_items
(item_list, source=None)¶ Merge items into the object table.
Parameters: - item_list – list of dictionaries of {‘name’, ‘created_at’, ‘size’, ‘content_type’, ‘etag’, ‘deleted’, ‘storage_policy_index’, ‘ctype_timestamp’, ‘meta_timestamp’}
- source – if defined, update incoming_sync with the source
-
put_object
(name, timestamp, size, content_type, etag, deleted=0, storage_policy_index=0, ctype_timestamp=None, meta_timestamp=None)¶ Creates an object in the DB with its metadata.
Parameters: - name – object name to be created
- timestamp – timestamp of when the object was created
- size – object size
- content_type – object content-type
- etag – object etag
- deleted – if True, marks the object as deleted and sets the deleted_at timestamp to timestamp
- storage_policy_index – the storage policy index for the object
- ctype_timestamp – timestamp of when content_type was last updated
- meta_timestamp – timestamp of when metadata was last updated
-
reported
(put_timestamp, delete_timestamp, object_count, bytes_used)¶ Update reported stats, available with container’s get_info.
Parameters: - put_timestamp – put_timestamp to update
- delete_timestamp – delete_timestamp to update
- object_count – object_count to update
- bytes_used – bytes_used to update
-
set_storage_policy_index
(policy_index, timestamp=None)¶ Update the container_stat policy_index and status_changed_at.
-
set_x_container_sync_points
(sync_point1, sync_point2)¶
-
storage_policy_index
¶
-
update_reconciler_sync
(point)¶
-
-
swift.container.backend.
update_new_item_from_existing
(new_item, existing)¶ Compare the data and meta related timestamps of a new object item with the timestamps of an existing object record, and update the new item with data and/or meta related attributes from the existing record if their timestamps are newer.
The multiple timestamps are encoded into a single string for storing in the ‘created_at’ column of the objects db table.
Parameters: - new_item – A dict of object update attributes
- existing – A dict of existing object attributes
Returns: True if any attributes of the new item dict were found to be newer than the existing and therefore not updated, otherwise False implying that the updated item is equal to the existing.
Container Server¶
-
class
swift.container.server.
ContainerController
(conf, logger=None)¶ Bases:
swift.common.base_storage_server.BaseStorageServer
WSGI Controller for the container server.
-
DELETE
(ctrl, *args, **kwargs)¶ Handle HTTP DELETE request.
-
GET
(ctrl, *args, **kwargs)¶ Handle HTTP GET request.
-
HEAD
(ctrl, *args, **kwargs)¶ Handle HTTP HEAD request.
-
POST
(ctrl, *args, **kwargs)¶ Handle HTTP POST request.
-
PUT
(ctrl, *args, **kwargs)¶ Handle HTTP PUT request.
-
REPLICATE
(ctrl, *args, **kwargs)¶ Handle HTTP REPLICATE request (json-encoded RPC calls for replication.)
-
account_update
(req, account, container, broker)¶ Update the account server(s) with latest container info.
Parameters: - req – swob.Request object
- account – account name
- container – container name
- broker – container DB broker object
Returns: if all the account requests return a 404 error code, HTTPNotFound response object, if the account cannot be updated due to a malformed header, an HTTPBadRequest response object, otherwise None.
-
allowed_sync_hosts
= None¶ The list of hosts we’re allowed to send syncs to. This can be overridden by data in self.realms_conf
-
create_listing
(req, out_content_type, info, resp_headers, metadata, container_list, container)¶
-
get_and_validate_policy_index
(req)¶ Validate that the index supplied maps to a policy.
Returns: policy index from request, or None if not present Raises: HTTPBadRequest if the supplied index is bogus
-
realms_conf
= None¶ ContainerSyncCluster instance for validating sync-to values.
-
save_headers
= ['x-container-read', 'x-container-write', 'x-container-sync-key', 'x-container-sync-to']¶
-
server_type
= 'container-server'¶
-
update_data_record
(record)¶ Perform any mutations to container listing records that are common to all serialization formats, and returns it as a dict.
Converts created time to iso timestamp. Replaces size with ‘swift_bytes’ content type parameter.
Params record: object entry record Returns: modified record
-
-
swift.container.server.
app_factory
(global_conf, **local_conf)¶ paste.deploy app factory for creating WSGI container server apps
-
swift.container.server.
gen_resp_headers
(info, is_deleted=False)¶ Convert container info dict to headers.
Container Replicator¶
-
class
swift.container.replicator.
ContainerReplicator
(conf, logger=None)¶ Bases:
swift.common.db_replicator.Replicator
-
brokerclass
¶ alias of
ContainerBroker
-
datadir
= 'containers'¶
-
default_port
= 6201¶
-
delete_db
(broker)¶ Ensure that reconciler databases are only cleaned up at the end of the replication run.
-
dump_to_reconciler
(broker, point)¶ Look for object rows for objects updates in the wrong storage policy in broker with a
ROWID
greater than the rowid given as point.Parameters: - broker – the container broker with misplaced objects
- point – the last verified
reconciler_sync_point
Returns: the last successful enqueued rowid
-
feed_reconciler
(container, item_list)¶ Add queue entries for rows in item_list to the local reconciler container database.
Parameters: - container – the name of the reconciler container
- item_list – the list of rows to enqueue
Returns: True if successfully enqueued
-
find_local_handoff_for_part
(part)¶ Look through devices in the ring for the first handoff device that was identified during job creation as available on this node.
Returns: a node entry from the ring
-
get_reconciler_broker
(timestamp)¶ Get a local instance of the reconciler container broker that is appropriate to enqueue the given timestamp.
Parameters: timestamp – the timestamp of the row to be enqueued Returns: a local reconciler broker
-
replicate_reconcilers
()¶ Ensure any items merged to reconciler containers during replication are pushed out to correct nodes and any reconciler containers that do not belong on this node are removed.
-
report_up_to_date
(full_info)¶
-
run_once
(*args, **kwargs)¶
-
server_type
= 'container'¶
-
-
class
swift.container.replicator.
ContainerReplicatorRpc
(root, datadir, broker_class, mount_check=True, logger=None)¶
Container Sync¶
-
class
swift.container.sync.
ContainerSync
(conf, container_ring=None, logger=None)¶ Bases:
swift.common.daemon.Daemon
Daemon to sync syncable containers.
This is done by scanning the local devices for container databases and checking for x-container-sync-to and x-container-sync-key metadata values. If they exist, newer rows since the last sync will trigger PUTs or DELETEs to the other container.
The actual syncing is slightly more complicated to make use of the three (or number-of-replicas) main nodes for a container without each trying to do the exact same work but also without missing work if one node happens to be down.
Two sync points are kept per container database. All rows between the two sync points trigger updates. Any rows newer than both sync points cause updates depending on the node’s position for the container (primary nodes do one third, etc. depending on the replica count of course). After a sync run, the first sync point is set to the newest ROWID known and the second sync point is set to newest ROWID for which all updates have been sent.
An example may help. Assume replica count is 3 and perfectly matching ROWIDs starting at 1.
First sync run, database has 6 rows:
- SyncPoint1 starts as -1.
- SyncPoint2 starts as -1.
- No rows between points, so no “all updates” rows.
- Six rows newer than SyncPoint1, so a third of the rows are sent by node 1, another third by node 2, remaining third by node 3.
- SyncPoint1 is set as 6 (the newest ROWID known).
- SyncPoint2 is left as -1 since no “all updates” rows were synced.
Next sync run, database has 12 rows:
- SyncPoint1 starts as 6.
- SyncPoint2 starts as -1.
- The rows between -1 and 6 all trigger updates (most of which should short-circuit on the remote end as having already been done).
- Six more rows newer than SyncPoint1, so a third of the rows are sent by node 1, another third by node 2, remaining third by node 3.
- SyncPoint1 is set as 12 (the newest ROWID known).
- SyncPoint2 is set as 6 (the newest “all updates” ROWID).
In this way, under normal circumstances each node sends its share of updates each run and just sends a batch of older updates to ensure nothing was missed.
Parameters: - conf – The dict of configuration values from the [container-sync] section of the container-server.conf
- container_ring – If None, the <swift_dir>/container.ring.gz will be loaded. This is overridden by unit tests.
-
allowed_sync_hosts
= None¶ The list of hosts we’re allowed to send syncs to. This can be overridden by data in self.realms_conf
-
conf
= None¶ The dict of configuration values from the [container-sync] section of the container-server.conf.
-
container_deletes
= None¶ Number of successful DELETEs triggered.
-
container_failures
= None¶ Number of containers that had a failure of some type.
-
container_puts
= None¶ Number of successful PUTs triggered.
-
container_report
(start, end, sync_point1, sync_point2, info, max_row)¶
-
container_ring
= None¶ swift.common.ring.Ring for locating containers.
-
container_skips
= None¶ Number of containers whose sync has been turned off, but are not yet cleared from the sync store.
-
container_stats
= None¶ Per container stats. These are collected per container. puts - the number of puts that were done for the container deletes - the number of deletes that were fot the container bytes - the total number of bytes transferred per the container
-
container_sync
(path)¶ Checks the given path for a container database, determines if syncing is turned on for that database and, if so, sends any updates to the other container.
Parameters: path – the path to a container db
-
container_sync_row
(row, sync_to, user_key, broker, info, realm, realm_key)¶ Sends the update the row indicates to the sync_to container. Update can be either delete or put.
Parameters: - row – The updated row in the local database triggering the sync update.
- sync_to – The URL to the remote container.
- user_key – The X-Container-Sync-Key to use when sending requests to the other container.
- broker – The local container database broker.
- info – The get_info result from the local container database broker.
- realm – The realm from self.realms_conf, if there is one. If None, fallback to using the older allowed_sync_hosts way of syncing.
- realm_key – The realm key from self.realms_conf, if there is one. If None, fallback to using the older allowed_sync_hosts way of syncing.
Returns: True on success
-
container_syncs
= None¶ Number of containers with sync turned on that were successfully synced.
-
container_time
= None¶ Maximum amount of time to spend syncing a container before moving on to the next one. If a container sync hasn’t finished in this time, it’ll just be resumed next scan.
-
devices
= None¶ Path to the local device mount points.
-
interval
= None¶ Minimum time between full scans. This is to keep the daemon from running wild on near empty systems.
-
logger
= None¶ Logger to use for container-sync log lines.
-
mount_check
= None¶ Indicates whether mount points should be verified as actual mount points (normally true, false for tests and SAIO).
-
realms_conf
= None¶ ContainerSyncCluster instance for validating sync-to values.
-
report
()¶ Writes a report of the stats to the logger and resets the stats for the next report.
-
reported
= None¶ Time of last stats report.
-
run_forever
(*args, **kwargs)¶ Runs container sync scans until stopped.
-
run_once
(*args, **kwargs)¶ Runs a single container sync scan.
-
select_http_proxy
()¶
-
sync_store
= None¶ ContainerSyncStore instance for iterating over synced containers
-
swift.container.sync.
random
() → x in the interval [0, 1).¶
Container Updater¶
-
class
swift.container.updater.
ContainerUpdater
(conf)¶ Bases:
swift.common.daemon.Daemon
Update container information in account listings.
-
container_report
(node, part, container, put_timestamp, delete_timestamp, count, bytes, storage_policy_index)¶ Report container info to an account server.
Parameters: - node – node dictionary from the account ring
- part – partition the account is on
- container – container name
- put_timestamp – put timestamp
- delete_timestamp – delete timestamp
- count – object count in the container
- bytes – bytes used in the container
- storage_policy_index – the policy index for the container
-
container_sweep
(path)¶ Walk the path looking for container DBs and process them.
Parameters: path – path to walk
-
get_account_ring
()¶ Get the account ring. Load it if it hasn’t been yet.
-
get_paths
()¶ Get paths to all of the partitions on each drive to be processed.
Returns: a list of paths
-
process_container
(dbfile)¶ Process a container, and update the information in the account.
Parameters: dbfile – container DB to process
-
run_forever
(*args, **kwargs)¶ Run the updater continuously.
-
run_once
(*args, **kwargs)¶ Run the updater once.
-
-
swift.container.updater.
random
() → x in the interval [0, 1).¶


Hello! I’m an Assistant Professor in the Computer Science department at Whitman College. I earned my PhD in Information Science at the University of Colorado in Boulder, advised by Brian Keegan. My research focuses on how how unexpected mechanisms - sound, art, taste, participatory experiences - can help people understand quantitative data. I also work with voice assistants and news. During my PhD career, I also completed human-computer interaction research internships at Yahoo, Mozilla, and Spotify.
Previously, I was a data journalist with Inside Energy, a public media collaboration, where I told complex stories in approachable ways using graphics, podcasting, live performances and more. I also worked with the Piton Foundation, where I helped people use neighborhood-level data to improve their communities.
I'm a co-creator and editor of the podcast Qualia, an immersive thought experiment in sound.
Oh, and I also run a lot ;)
Thank you, Bootstrap, for saving me time while I built this.


@*
* Copyright 2021 HM Revenue & Customs
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*@
@import views.html.helper.CSRF
@import uk.gov.hmrc.cataloguefrontend.AuthController.SignInData
@(form: Form[SignInData], selfServiceUrl: String)(implicit request: Request[_], messages: Messages)
@standard_layout("Sign-in", "sign-in") {
Sign in to Catalogue
To perform actions on the Catalogue please sign in using your LDAP credentials
@if(form.hasErrors) {You can reset your password at @selfServiceUrl
}


Objective
I am a goal-oriented, passion-driven individual excited about getting into the front-end tech industry. I have a diverse professional background with proven skills in leadership, development, and project management. I have gained a wealth of technical knowledge through The Iron Yard in the past months, and wish to continue my learning as I begin my career.
Technical Skills
JavaScript
- Comfortable with Vanilla JavaScript, for strong foundational understanding and responsive sites
- Proven experience with JQuery, Node.js, and LoDash
- Constructed final project of a dynamic web application with AngularJS
CSS and Sass
- Comfortable with writing both CSS and SCSS files
- Can create my own grid system and have comfort with box-sizing
- Worked extensively with Bootstrap and understand its’ component classes
- Familiar with current web application style choices
HTML5
- Skilled at writing readable and maintainable HTML
- Gaining familiarity with writing XML
Firebase and APIs
- First hand experience in with posting and getting data from Firebase
- Worked with nesting database structures to organize data as needed
- Exposed to additional databases including mySQL
- Used various restful APIs including Github, Etsy, BreweryDB, and YouTube
Additional Technologies
- Familiar with Gulp-Webapp, Gulp-Angular, and H5BP Boilerplates
- Experienced with GulpJS and Browser-Sync for browser testing
- Proficient at the command line as well as package managers Npm, Bower, and BrewMaster
- Daily use of Github and Git command tools
- Use of Mocha and Chai to test code
- Comfortable with the concept and writing of the MVC structure
General Skills
- Gained a broad level of knowledge by working on a variety of upwards of 20 projects during The Iron Yard
- Enjoyed team-based cohort learning style, creating close bonds by working on a team
- Worked independently to successfully meet goals and complete projects
- Proven ability to learn quickly and adapt to a fast-pace environment
- Able to read, understand, and refactor code to be more semantic
- Desire to learn new technologies and continually advance my coding knowledge
Education
- The Iron Yard (Orlando, Florida) - Front End Engineering, Graduation August 2015
- The College of Wooster (Wooster, Ohio) - Bachelor of Arts, Graduation May 2007
- Charles University (Prague, Czech Republic) - Study Abroad
- St. Vincent - St. Mary High School (Akron, Ohio) - Graduation May 2003
Work Experience
JPMorgan Chase
Corporate Trainer for Knowledge Network
Lake Mary, FL
March 2011- May 2015
- Responsible for the continual development of newly hired and tenured employees through conducting training sessions. Sessions ranged from one hour to eight weeks and focused on customer experience, bank compliance, computer technology, and improving business success
- Monitor trainings from initial inception to full fruition while using Adult Learning theories. Work closely with our design team, business owners, and marketing teams to help create a seamless learning experience for the specialist
- Daily responsibilities include management of a classroom environment, in depth coaching of individuals, use of presentation skills, monitoring customer satisfaction through metrics such as Net Promoter score, and striking a balance between operational goals and organizational strides
- Became fully certified to train Way to Wow, an in-depth customer-focused learning experience. Introduced Way to Wow to business leaders, leading to its expansion to a global audience. Attended courses such as Art of Leadership, Creating an Inclusive Work Environment, Holistic Coaching, Adult Education, Virtual Training, and more
- Thrived within Chase’s face-paced learning environment and became integral to business success. Recognized with an Exceeds Expectations rating and laying the groundwork for becoming a senior trainer within 2014
Macy’s Inc.
Retail Services Training Supervisor
Mason, OH
Oct 2008 – Jan 2011
- Taught teams of associates to be proficient in retail service inquiries. Managed training process from design through facilitation. Educated employees on various products from ready-to-wear to large-ticket sales
- Daily responsibilities included; professional communication through facilitation, multi-tasking, teamwork, coaching, computer usage, developing partnerships, and classroom organization
- Attended several development classes on facilitation, leadership, customer centric training, and instructional design
- Took full advantage of tremendous learning experience and traveled to Manila, Philippines in the fall of 2010
- Assisted with the start up and maintenance of employed staff providing Macys.com online support
Internet Customer Service Associate
Oct 2007 - Oct 2008
- Developed strong customer service and computer skills by using creativity to solve customer concerns
- Procured additional tasks such as backline computer functions, peer coaching, and specialty projects
Tomahawk Ranch Girl Scout Camp
Unit Leader
Bailey, CO
Summer 2006
- Guided week-long overnight camping sessions for girls age 7-17
- Supervised 4-8 counselors weekly for whom feedback and communication was essential
- Managed the unit through activities, cooking, camping, and safety while creating memorable experiences
- Learned many skills including supervising international staff, wilderness awareness, program planning, confidential information, first aid, parent communications, and group conflict resolution


|
|
| MNISTData (std::vector< std::string > paths, std::vector< Ptr< Vocab >> vocabs={}, Ptr< Config > options=nullptr) |
| |
|
void | loadData () override |
| |
|
Example | next () override |
| |
|
| Dataset (std::vector< std::string > paths) |
| |
|
iterator | begin () override |
| |
|
iterator | end () override |
| |
|
void | shuffle () override |
| |
|
batch_ptr | toBatch (const Examples &batchVector) override |
| |
|
| DatasetBase (std::vector< std::string > paths) |
| |
|
virtual batch_ptr | toBatch (const std::vector< sample > &)=0 |
| |
|
virtual void | reset () |
| |
|
virtual void | prepare () |
| |
|
virtual void | restore (Ptr< TrainingState >) |
| |
|
| RNGEngine (size_t eng) |
| |
|
std::string | getRNGState () |
| |
|
void | setRNGState (std::string engineState) |
| |
|
|
typedef DataBatch | batch_type |
| |
|
typedef Ptr< DataBatch > | batch_ptr |
| |
|
typedef ExampleIterator | iterator |
| |
|
typedef Example | sample |
| |
|
Examples | examples_ |
| |
|
std::vector< std::string > | paths_ |
| |
|
std::mt19937 | eng_ |
| |
The documentation for this class was generated from the following file:


ACKNOWLEDGEMENT
The code for this demo has been adapted from the NASA WebWorldWind project and extensively modified. The original copyright notice is reproduced below.
COPYRIGHT
Copyright 2003-2006, 2009, 2017, United States Government, as represented by the Administrator of the National Aeronautics and Space Administration. All rights reserved. The NASAWorldWind/WebWorldWind platform is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.


This intention pick up editor selection and, iff it is has array or java.lang.Iterable type, iterates over it. When editor doesn't contain selection, appropriate expression under caret would be picked up


Result
Score: 0
Best score: 0
Time of played: 0s.
FPS:0
Settings
Speed:
How To Play
After the game starts, you should press ↑↓←→ to control the direction of the snake.
If your snake eats itself or crashes into the wall, you will lose.


UK Labour Party undergoing second cyber attack: source
LONDON (Reuters) - Hackers attacked Britain’s opposition Labour Party for a second time in two days on Tuesday and attempted to force its web services offline, according to a person with knowledge of the matter and documents seen by Reuters.
The attack began at around 1320 GMT and peaked about an hour later, the source said, just hours after the Labour Party announced it had repelled a similar attack on Monday evening.
A Labour Party spokesman had no immediate comment.
The source said both attacks were “very unsophisticated” distributed denial-of-service (DDoS) attacks which try to take down target websites by flooding them with malicious traffic.


"We started with having Neil pour us a new patio and that
expanded into partial driveway along the house. He was quick,
efficient, super nice guy, and took pride in his work. He also
made sure the work site was cleaned up. Will definitely be
calling him again when we are ready to redo the rest of the
driveway."
-Tabitha
"Douglas Excavation was quick to my rescue when I needed help
moving some dirt as well as a rough grade on my new
construction. I couldn't recommend him more - he is courteous
and timely."
-Amber
"When I truly needed someone to help me fix my water lines, he
was there. The fact that it was a Saturday was an incredible
kind thing to do. I am incredibly grateful for him today for
helping me get my grooming shop back with water and fixing an
"old" problem."
-Kathy
Owner and Operator
Born and raised in Northern Indiana, Neil operates Douglas Excavation out of Brookston, Indiana. You can keep up with the company's work on the Douglas Excavation Facebook page.


Copyright ©2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
A URI reference may include an optional fragment identifier that consists of additional reference information to be interpreted by the user agent after the URI has been successfully retrieved. The format and interpretation of fragment identifiers is dependent on the media type of the retrieval result. The XML media type can therefore specify a fragment identifier syntax that takes advantage of the XML structure to define ways to point into an XML resource. This document recommends the adoption of a specific fragment identifier syntax for use with XML resources.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This proposal for an XML fragment-identifier syntax was prepared by the XML Linking Working Group as part of its work, before its charter expired and the Working Group went out of existence in December 2002. It is published now (on 12 September 2003) to encourage discussion; comments on the proposal are invited.
This document represents the majority, but not unanimous, recommendation of the XML Linking Working Group. A minority would have preferred to omit the element() scheme from this recommendation.
This is a W3C Working Group Note for review by W3C Members, IETF members, and other interested parties. It has been produced as part of the XML Activity. Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Patent disclosures relevant to this specification may be found on the Working Group's public patent disclosure page.
This is work in progress and does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR.
Comments and discussion on this document should be sent to<EMAIL_ADDRESS>(public archive).
RFC 2396 [RFC2396] defines the generic syntax for a Uniform Resource Identifier (URI). It defines a URI reference as a URI that may have additional information attached in the form of a fragment identifier. It describes fragment identifiers as follows:
When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. ...
The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. ... Individual media types may define additional restrictions or structure within the fragment for specifying different types of “partial views” that can be identified within that media type.
A fragment identifier is only meaningful when a URI reference is intended for retrieval and the result of that retrieval is a document for which the identified fragment is consistently defined.
The XML media type ([RFC2376] and [RFC 3023]) can therefore specify a fragment identifier syntax that takes advantage of the XML structure to define ways to point into an XML resource. This document suggests a specific fragment identifier syntax and recommends that the XML media type be augmented to adopt this syntax as the fragment identifier syntax for use with XML resources.
The W3C XLink Working Group is developing the XPointer family of specifications to support addressing into the internal structures of XML documents, and it seems this work should be the basis for any fragment identifier syntax for XML. However, given that all processes are generally required to support fragment identifiers, there is a strong case to be made for assuring that the core of any fragment identifier syntax is as simple as possible. In consideration of this need for simplicity, this document recommends something less than full XPointer be adopted as the fragment identifier syntax for XML resources.
It is the position of this Working Group that the minimum requirement for an XML fragment identifier is the ability to identify any element in any XML resource.
One of the key methods of identifying XML elements are ID-typed element and attribute values. IDs are robust ways to identify a given element if the element that needs to be identified already has an ID or can have an ID added to it. But this requires that the element allow an ID attribute and in general that the document can be modified. However, there are many important user requirements for pointing into an XML resource where it is not practical or possible for the resource to be modified.
The element structure itself can be used to identify any specific element in a document without requiring any specific information (such as an ID). Taking advantage of the element structure allows for the unambiguous identification of any element in an XML resource without requiring any modification of the document.
Given the widespread use of fragment identifiers and the scope of XPointers in particular and URI references in general, it is not a user requirement to be able to write “query-like” statements in the fragment identifier. Furthermore, XML structures such as processing instructions, attributes, and comments are probably not in the 80/20 part of the solution, as the cost in terms of added complexity to the syntax and processing requirements of being able to access such structures is not worth the benefits.
Therefore, this document recommends the use of IDs and element structure to form the basis of the fragment identifier syntax for the XML MIME type.
This document recommends that the XML media type define its fragment identifier syntax to be that defined by the XPointer Framework [XPtrFrame] and XPointer Element() Scheme [XPtrElement].
The following are some fragment identifiers allowed by this definition:
Intro SKU153976 element(/1/5/4/3) element(Terminology/3/1/2) xpointer(id('boy-blue')/horn[1])element(boy-blue/3)
Note that in the last example, a processor minimally conforming to the fragment identifier definition proposed in this document would not be required to recognize or handle the xpointer(id('boy-blue')/horn[1])
pointer part, it would merely be required (by conformance to the Framework specification) to properly skip over it to find and process the element(boy-blue/3)
pointer part.
Assuming the recommendation of this document is reflected in an update to the definition of the XML Media type, a processor claiming to be able to handle URI references to XML resources must be able to handle any valid URI reference with a fragment identifier than conforms to the XPointer Framework and XPointer element() Scheme Recommendations.