In Xtext 15 minutes tutorial (here) the Entity rule is defined as follows
Entity:
'entity' name = ID ('extends' superType = [Entity])? '{'
features += Feature*
'}'
;
which means that after word "extends" parser should expect reference to (another) entity. How is it set that actually here should be used ID rule? What if I have no ID rule in my grammar?
The cross references in superType = [Entity] is a shorthand notation for superType = [Entity|ID]. If you use superType = [Entity|STRING], references will be based on the concrete syntax of the terminal rule STRING.
Related
In the following Alloy model I want to check the equality of two instances of a sig with Bool field type:
module test
open util/boolean as bool
sig Info {
active: Bool
}
assert assertion {
all x1, x2: Info |
x1.active = True && x2.active = True implies x1 = x2
}
check assertion for 10
This model checks for equality of x_1 and x_2 if both have True as their active field. Alloy comes back with a counterexample, however, in the counterexample, both x_1 and x_2 are structurally equal but for some reason Alloy considers them not equal.
Edit:
One suggestion is to use subtyping as follows:
sig Info {}
sig ActiveInfo in Info {}
-- i is inactive if i in (Info - ActiveInfo)
However, this is not suitable for my model.
Quote from the Software Abstractions book:
"
Is equality structural equality or reference equality?
A relation has no identity distinct from its value, so this distinction,
based on programming notions, doesn’t make sense here. If two relations have the same set of tuples, they aren’t two relations: they’re just
one and the same relation. An atom is nothing but its identity; two atoms are equal when they are the same atom. If you have a set of atoms
that represent composite objects (using some relations to map the atoms to their contents), you can define any notion of structural equality
you want explicitly, by introducing a new relation. (And for those C++
programmers out there: no, you can’t redefine the equals symbol in Alloy.)"
I don't quite understand this paragraph. I appreciate explanation on how equality works in Alloy. Particularly on how to check equalities of atoms with different identities but same values?
I know that equality in Alloy is based on values.
This is not true. x1 and x2 have the same value for active, but are different atoms in the signature. It's similar to how in a lot of OOP languages, two objects can have the same structural values but have different identities.
Incidentally, I'd recommend using subtypes to represent booleans. You could do
sig Info {}
sig ActiveInfo in Info {}
-- i is inactive if i in (Info - ActiveInfo)
You can think of a field in a signature as "belonging" to an atom of that signature if you like, but it's better just to think of fields as relations. You wouldn't expect two persons to be the same if they have the same mother:
sig Person {mother: Parent}
But if you want your signature to have the property that no two distinct members have the same fields, you can just add that as a fact:
sig Coordinate {x, y: Value}
fact {all c, c': Coordinate | (c.x = c'.x and c.y = c'.y) implies c = c'}
I am using Corda 4.0 and I want to run a custom query with dynamic column name (colN) and column value (colC). Here is my code for the query building
builder {
val index: CriteriaExpression.ColumnPredicateExpression<Any,String> = getField(colN,CarSchemaV1.PersistentCar::class.java).equal(colC)
val customCriteria = QueryCriteria.VaultCustomQueryCriteria(index)
}
But I am getting a error in compile time
Type parameter bound for L in constructor VaultCustomQueryCriteria<L: PersistableState>(expression: CriteriaExpression<L,Boolean>,...) is not satisfied: inferred typed Any is not a subtype of StatePersistable
the issue here has to do with your use of Any in the generics of CriteriaExpression.ColumnPredicaeExpression<Any, String>. As indicated by the error message, instead of using Any you should be using a subtype of StatePersistable
According to the docs: net.corda.core.schemas.StatePersistable
Marker interface to denote a persistable Corda state entity that will always have a transaction id and index
Your schema CarSchemaV1.PersistentCar::class.java likely implements PersistentState. Try adding that into your generics.
val index: CriteriaExpression.ColumnPredicateExpression<CarSchemaV1.PersistentCar,String> = getField(colN,CarSchemaV1.PersistentCar::class.java).equal(colC)
I'm trying to enter our database model into ALFA in order to check the capabilities of ALFA and XACML.
Are attributes like the following possible? How would look the rules then?
1:n by list of strings
namespace com.mycompany {
namespace resources {
namespace patient {
attribute trustedDoctorIds{
category = resourceCat
id = "trustedDoctorIds"
type = list<string> //maybe it should be bag[string]
}
}
}
}
1:n by list of complex type
namespace com.mycompany {
namespace resources {
namespace patient {
attribute trustedDoctors{
category = resourceCat
id = "trustedDoctors"
type = list<doctor> //maybe it should be bag[doctor]
}
}
}
namespace subjects {
namespace doctor {
attribute id {
category = subjectCat
id = "id"
type = string
}
attribute lastname {
category = subjectCat
id = "lastname"
type = string
}
}
}
}
You have a great question there.
By default all attributes in ALFA and XACML are multi-valued. Attributes are bags of values rather than single values. This means that when you define the following,
attribute trustedDoctorIds{
category = resourceCat
id = "trustedDoctorIds"
type = string
}
This means the attribute has a type of string and it can be multi-valued. You could choose to express cardinality information in the comments above the attribute definition e.g.
/**
* This attribute, trustedDoctorIds, contains the list of doctors a patient
*trusts. The list can have 0 or more values.
*/
The policy is the one that will convey how many values there can be depending on the functiosn being used.
For instance, you could write a condition that states
stringOneAndOnly(trustedDoctorIds)==stringOneAndOnly(userId)
In that case, you are forcing each attribute to have one value and one value only. If you have 0 or more than 1 value, then the evaluation of the XACML policy will yield Indeterminate.
In a XACML (or ALFA) target, when you write:
trustedDoctorIds == "Joe"
You are saying: if there is at least one value in trustedDoctorIds equal to 'Joe'...
In an ALFA condition, when you write
trustedDoctorIds==userId
You are saying: *if there is at least one value in trustedDoctorIds equal to at least one value in userId
Note: I always use singular names for my attributes when I can. It's a convention, not a hard limit. Remembering the cardinality of your attributes will help later in your policy testing.
Answers to the comments
What would be a plural name you try to avoid by your convention?
Well trustedDoctorId***s*** looks rather plural to me. I would use trustedDoctorId unless you know that the attribute is necessarily always multi-valued.
So, this should be possible: In my request I provide resource.patient.trustedDoctorIds=="2,13,67" and subject.doctor.id=="6". How would the rule then look like in ALFA? Smth. like "resource.patient.trustedDoctorIds.contains(subject.doctor.id) permit"
The rule would look like the following:
stringIsIn(stringOneAndOnly(subject.doctor.id),resource.patient.trustedDoctorIds)
Make sure that you provide multiple values in your request, not one value that contains comma-separated values. Send in [1,2,3] rather than "1,2,3".
Further edits
So, by [2,13,67] the result is deny as expected and not permit like with "2,13,67" and doctorId==6. I chose that example on purpose, since the stringIsIn function would result unwantedly with true since 6 is included in 67
Do not confuse stringIsIn() and stringContains().
stringIsIn(a, b) takes in 2 parameters a and b where a is an atomic value and b is a bag of values. stringIsIn(a, b) returns true if the value of a is in the bag of values of b.
stringContains(a, b) takes in 2 parameters a and b that are both atomic values of type string. It returns true if the string value a is found inside b.
Example:
stringIsIn(stringOneAndOnly(userCitizenship), stringBag("Swedish", "German")) returns true if the user has a single citizenship equal to either of Swedish or German.
stringContains("a", "alfa") returns true if the second string contains the first one. So it returns true in this example.
I'm reading through Paulson's ML For the Working Programmer and am a bit confused about the distinction between datatypes and structures.
On p. 142, he defines a type for binary trees as follows:
datatype 'a tree = Lf
| Br of 'a * 'a tree * 'a tree;
This seems to be a recursive definition where 'a denotes some fixed type. So any time I see 'a, it must refer to the same type throughout.
On p. 148, he discusses a structure for binary trees:
"...we have been following an imaginary ML session in which we typed in the tree functions one at a time. Now we ought to collect the most important of those functions into a structure, called Tree. We really must do so, because one of our functions (size) clashes with a built-in function. One reason for using structures is to prevent such name clashes.
We shall, however, leave the datatype declaration of tree outside of the structure. If it were inside, we should be forced to refer to the constructors by Tree.Lf and Tree.Br, which would make our patters unreadable. Thus, in the sequel, imagine that we have made the following declarations:
datatype 'a tree = Lf
| Br of 'a * 'a tree * 'a tree;
structure Tree =
struct
fun size Lf = 0
| size (Br( v, t1, t2)) = 1 + size t1 + size t2;
fun depth...
etc...
end;
I'm a little confused.
1) What is the relationship between a datatype and a structure?
2) What is the role of "struct" within the structure definition?
3) Later on, Paulson discusses a structure for dictionaries as binary search trees. He does the following:
structure Dict : DICTIONARY =
struct
type key = string;
type 'a t = (key * 'a) tree;
val empty = Lf;
<a bunch of functions for dictionaries>
This makes me think struct specifies the different primitive or compound types involved int he definition of a Dict.
That's a really fuzzy definition though. Anyone like to clarify?
Thanks for the help,
bclayman
A structure is a module. Everything between the struct and end keywords forms the body of this module. Similarly, you can view a signature as the description of an abstract module interface. Ascribing a signature to a structure (like the : DICTIONARY syntax does in your example) limits the exports of the module to what is specified in that signature (by default, everything would be accessible). That allows you to hide implementation details of a module.
However, ML modules are much richer than that. They can be arbitrarily nested. There are also functors, which are effectively functions from modules to modules ("parameterised modules", if you want). Altogether, the module language in ML forms a full functional language on its own, with structures as the basic entities, functors over them, and signatures describing the "types" of such modules. This little language is a layer on top of the so-called core language, where ordinary values and types live.
So, to answer your individual questions:
1) There is no specific relationship between the datatype and the structure. The latter simply uses the former.
2) struct-end is simply a keyword pair to delimit the structure body (languages in C tradition would probably use curly braces there).
3) As explained above, a structure is a basic module. It can contain (and export) arbitrary other language entities, including other modules. By grouping definitions together, and potentially hiding some of them through a signature ascription, you can express namespacing and encapsulation (in particular, abstract data types).
I should also note that Paulson's book is outdated regarding its description of modules, as it predates the current language version. In particular, it does not describe how to express abstract data types through modules, but instead introduces the obsolete abstype declaration which nobody has been using in almost 20 years. A more extensive and up-to-date introduction to modular programming in ML can be found in Harper's Programming in Standard ML.
In this example, the datatype 'a tree is describing a binary tree (https://en.wikipedia.org/wiki/Binary_tree) that is capable of storing any value of a single type. The 'a in the definition is a variant type which will later be constrained down to a concrete type wherever tree is used with a different type. This allows you to define the structure of a tree once and then use it with any type later on.
The Tree structure is separate from the datatype definition. It is being used to group functions together that operate on the 'a tree datatype. It is being used right now as a way to modularize the code and, as it points out, to prevent namespace clashes.
struct is just an identifier keyword to let the compiler know where your structure definition starts while the end keyword is used to let the compiler know where the definition ends.
The dictionary structure is defining a dictionary (a key -> value data structure) that uses a tree as the internal data structure. Once again, the structure is a collection of functions that will be used to create and operate on dictionaries. The types within the dictionary structure compose the type of the internal data structure that makes up the dictionary. The following functions define the public interface that you're exposing to allow clients to work with dictionaries.
According to the protege 4.x documentation the property chain exists for the object properties however in my case I need to include a data property as follow:
if builds(B, A) o has_name(A, "Holly wood") -> has_name(B, "Holly wood")
To explain a bit, imagine we have a street with a name "Holly wood". This street is built of several segments (a segment is a part of street between to junctions) whose name should be the same as street name "Holly wood".
Note that, the street concept is different from the segment so they are not subclasses but they have the above relation (builds).
One solution is to make the has_name an Object property, then each name should be an object (instance).
if is_name_of(name, A) o is_built_of(A, B) -> is_name_of(name, B)
This does not seem quite OK to me as I think it is better to use data-type.
the other solution is to use SWRL as below:
Thing(?p), Thing(?q), builds(?q, ?p), has_name(?p, ?name) -> has_name(?q, ?name)
this does not work!!!!
can you help me figure out why or find a proper solution?
I think that the SWRL rule is the proper solution here. As you've noted, you can't use the data property in a subproperty chain axiom, but you would need to in order to get the behavior you're looking for. The structural specification for object subproperty axioms and for data subproperty axioms are:
9.2.1 Object Subproperties
SubObjectPropertyOf := 'SubObjectPropertyOf' '(' axiomAnnotations subObjectPropertyExpression superObjectPropertyExpression ')'
subObjectPropertyExpression := ObjectPropertyExpression | propertyExpressionChain
propertyExpressionChain := 'ObjectPropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
9.3.1 Data Subproperties
SubDataPropertyOf := 'SubDataPropertyOf' '(' axiomAnnotations subDataPropertyExpression superDataPropertyExpression ')'
subDataPropertyExpression := DataPropertyExpression
superDataPropertyExpression := DataPropertyExpression
OWL 2 simply doesn't have a property chain expression that mixes object and datatype properties. Thus, you'd need to use a SWRL rule. You can use a rule like this (there's no need to use Thing(?p) ∧ Thing(?q), since every individual is automatically an owl:Thing):
builds(?q, ?p) ∧ has_name(?p, ?name) → has_name(?q, ?name)