Commit 8d5e4344 authored by Ryan Berkheimer's avatar Ryan Berkheimer

resolve all markdown linter issues in README and DeveloperWorkLog

parent aeccbbe5
......@@ -58,8 +58,7 @@ Currently fields are specified by transformations on transformation spec maps, a
#### Design Path
Ultimately it was decided that the best that could be done with endpoint fields without breaking some mathematical domain guarantees was to create a BaseEndpoint abstract class, which other endpoints could extend, that would parse default fields (to be specified on the endpoint itself). This design allows consumers of endpoints to have a guarantee of what fields they will expect to originate out of an endpoint. In the specification, a subset of those fields can be specified to restrict what endpoints return. This design compromise was due to the uncertainty in the field domain of reusable endpoints - i.e., the possibility for endpoints to define fields with the same name but different types. This could either be controlled via
Ultimately it was decided that the best that could be done with endpoint fields without breaking some mathematical domain guarantees was to create a BaseEndpoint abstract class, which other endpoints could extend, that would parse default fields (to be specified on the endpoint itself). This design allows consumers of endpoints to have a guarantee of what fields they will expect to originate out of an endpoint. In the specification, a subset of those fields can be specified to restrict what endpoints return. This design compromise was due to the uncertainty in the field domain of reusable endpoints - i.e., the possibility for endpoints to define fields with the same name but different types. This could either be controlled via
### Collection Conditions
......@@ -75,7 +74,7 @@ The goal is to implement condition behavior, similar to that currently seen at t
Currently, we have conditions listed as a list of maps, e.g.
```
```json
"conditions": [
{
"id": "1",
......@@ -99,8 +98,7 @@ Currently, we have conditions listed as a list of maps, e.g.
And we have a list of collections in another list of maps, e.g.,
```
```json
"collections": [
{
"id": "required-fields",
......@@ -199,10 +197,10 @@ of records that satisfy the conditions specified by the transformation.
- method should select data from the protocol record records map
- method should allow any combination of record sets to be used in transformations
- method should allow as record set parameters
- collections
- classifiers
- uuids
- other transformations
- collections
- classifiers
- uuids
- other transformations
**We want the internal behavior to conform to the following conditions**
......
This diff is collapsed.
......@@ -63,7 +63,9 @@ FF=gfortran
#The following vars contain strings representing common libraries used by all code
#at a project level. These should generally not be touched by users.
COMMONC=
COMMONCPP=JniUtils.cpp TypeUtils.cpp ListUtils.cpp ConditionUtils.cpp FieldUtils.cpp EndpointUtils.cpp ProtocolRecordUtils.cpp RecordUtils.cpp RejectionUtils.cpp PacketUtils.cpp MessageApiEndpoint.cpp MessageApiEndpointLib.cpp
COMMONCPP=JniUtils.cpp TypeUtils.cpp ListUtils.cpp ConditionUtils.cpp FieldUtils.cpp \
EndpointUtils.cpp ProtocolRecordUtils.cpp RecordUtils.cpp RejectionUtils.cpp PacketUtils.cpp \
MessageApiEndpoint.cpp MessageApiEndpointLib.cpp
COMMONFORTRAN=
JAVACLASSES:=$(PROJECTPATH)/src/java/main/gov/noaa/messageapi/endpoints/NativeEndpoint.java
JAVAPATH=$(PROJECTPATH)/src/java/main:$(PROJECTPATH)/src/java/main/gov/noaa/messageapi/endpoints
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment