jpl-imce/gov.nasa.jpl.imce.oml.development.generators

OML Development Generators

gov.nasa.jpl.imce.oml.development.generators's Issues

Code generation update for parallel sorting

See JPL-IMCE/gov.nasa.jpl.imce.oml.converters#52

Subtle code generation bugs affect the OML Converter's merge function

• Frameless:

Instead of:

tables.LiteralValue.fromJSON(s"""{"literalType":"${tuple.literalValueLiteralType}","value":"${tuple.literalValue}"}"""),

Need:

tables.LiteralValue.fromJSON(s"""{"literalType":"${tuple.literalValueLiteralType}","value":${Json.fromString(tuple.literalValue).toString}}"""),

The reason is that the OML tabular representation may have strings that contain characters like "; which need to be properly quoted for a valid Json string.

Also:

  protected def void readNumericScalarRestrictions(Extent ext, ArrayList<String> lines) {
  	val kvs = OMLZipResource.lines2tuples(lines)
  	while (!kvs.empty) {
  	  val kv = kvs.remove(kvs.size - 1)
  	  val oml = createNumericScalarRestriction()
  	  val uuid = kv.remove("uuid")
  	  val minExclusive_value = kv.remove("minExclusive")
  	  if (null !== minExclusive_value && minExclusive_value.length > 0)
  	  	oml.minExclusive = OMLTables.toLiteralNumber(minExclusive_value)
  	  val minInclusive_value = kv.remove("minInclusive")
  	  if (null !== minInclusive_value && minInclusive_value.length > 0)
  	  	oml.minInclusive = OMLTables.toLiteralNumber(minInclusive_value)
  	  val maxExclusive_value = kv.remove("maxExclusive")
  	  if (null !== maxExclusive_value && maxExclusive_value.length > 0)
  	  	oml.maxExclusive = OMLTables.toLiteralNumber(maxExclusive_value)
  	  val maxInclusive_value = kv.remove("maxInclusive")
  	  if (null !== maxInclusive_value && maxInclusive_value.length > 0)
  	  	oml.maxInclusive = OMLTables.toLiteralNumber(maxInclusive_value)
  	  oml.name = OMLTables.toLocalName(kv.remove("name"))
  	  val pair = new Pair<NumericScalarRestriction, Map<String,String>>(oml, kv)
  	  numericScalarRestrictions.put(uuid, pair)
  	  includeNumericScalarRestrictions(uuid, oml)
  	}
  }

Should check for a null string too!

Update for new SpecializedReifiedRelationship pattern

See JPL-IMCE/gov.nasa.jpl.imce.oml#238

Update code generation templates for OML datatypes

The OML metamodels in *.xcore use Xcore datatype aliases & wrapper classes.

Examples of datatype aliases:

type DateTimeDataType wraps gov.nasa.jpl.imce.oml.model.datatypes.DateTimeValue

type LanguageTagDataType wraps gov.nasa.jpl.imce.oml.model.datatypes.LanguageTagValue

type StringDataType wraps gov.nasa.jpl.imce.oml.model.datatypes.StringValue

type UUIDDataType wraps gov.nasa.jpl.imce.oml.model.datatypes.UUIDValue 

type URIDataType wraps gov.nasa.jpl.imce.oml.model.datatypes.URIValue

Examples of datatype wrapper classes:

abstract class LiteralValue {}

class LiteralDateTime extends LiteralValue {
	DateTimeDataType[1] dateTime
}

class LiteralString extends LiteralValue {
	StringDataType[1] string
}
...

Due to the restriction for context-free parsing of lexical tokens in Xtext (see: https://www.eclipse.org/Xtext/documentation/301_grammarlanguage.html#datatype-rules),
datatype wrapper classes are necessary to abstract different kinds of disjoint lexical tokens (e.g., DateTimeDataType, StringDataType, ...) as values for a common abstract datatype (e.g., LiteralValue).

However, this requires updating the code generators to recognize datatype aliases and wrappers.
For the latter, this entails that a "datatype attribute" in Xcore may be a composite typed by an abstract datatype wrapper class; e.g.:

class ScalarOneOfLiteralAxiom extends TermAxiom {
	
	refers ScalarOneOfRestriction[1] axiom
	
	/*
	 * The value of the literal from the restrictedScalar datatype
	 */
	contains LiteralValue[1] value
	...
}

Relax requirements for loading OMLZipResource

See JPL-IMCE/gov.nasa.jpl.imce.oml#219

Minor fixes

For xtend: OMLSpecificationTables.read*Restrictions parse "null" as no value.
For scala: Pattern for restriction metaclasses for OML Frameless representation.

Fix plural spelling for table names

AnnotationPropertys.json
EntityScalarDataPropertys.json
EntityStructuredDataPropertys.json
ScalarDataPropertys.json
StructuredDataPropertys.json

Update for OMLZipResource.load

See: JPL-IMCE/gov.nasa.jpl.imce.oml#244

Generated OML table spec has duplicate fields "annotations" and "annotationPropertyValues"

Generate companion object query functions for Extent-based queries methods

Example.

Currently:

trait Resource
{

  def iri
  ()(implicit extent: Extent): scala.Option[gov.nasa.jpl.imce.oml.tables.IRI]
  def name
  (): gov.nasa.jpl.imce.oml.tables.LocalName
  def abbrevIRI
  ()(implicit extent: Extent): scala.Option[scala.Predef.String]
}

Desired:

trait Resource
{

  def iri
  ()(implicit extent: Extent): scala.Option[gov.nasa.jpl.imce.oml.tables.IRI]
  def name
  (): gov.nasa.jpl.imce.oml.tables.LocalName
  def abbrevIRI
  ()(implicit extent: Extent): scala.Option[scala.Predef.String]
}

object Resource {
  def iri
  (r: Resource, extent: Extent)
  : scala.Option[gov.nasa.jpl.imce.oml.tables.IRI]
  = r.iri()(extent)
  
  def abbrevIRI
  (r: Resource, extent: Extent)
  : scala.Option[scala.Predef.String]
  = r.abbrevIRI()(extent)
}

Currently, the trait query methods cannot be passed as arguments because of the implicit parameter. With the companion object query functions, it is possible to pass such functions as arguments.

Code generation for @DerivedUUID needs to ignore optional attributes.

This affects several OML elements including JPL-IMCE/gov.nasa.jpl.imce.oml#147

Code generation for deterministic OMLZip timestamps

See JPL-IMCE/gov.nasa.jpl.imce.oml#276

Code generation update for API change

See JPL-IMCE/gov.nasa.jpl.imce.oml#258

Code generation for EMF/OMLZIP serialization

See JPL-IMCE/gov.nasa.jpl.imce.oml#175

Update OML SQL Schema generation and Frameless/SQL conversions.

See JPL-IMCE/gov.nasa.jpl.imce.oml#194

Code generation update for bijective catalog conversions.

See: JPL-IMCE/gov.nasa.jpl.imce.oml#230

Generate SQL schema for OML.

Code generation for ValueCrossReferenceKind

Generate Spark/GraphX vertexId

To facilitate using Apache Spark & GraphX on OML, generate a vertexId long identifier.

Need to strip quotes around IRI and UUID cross references

See JPL-IMCE/gov.nasa.jpl.imce.oml#183

Code generation update for cyclic OML ModuleEdges

See: JPL-IMCE/gov.nasa.jpl.imce.oml#242

Add support for typed OML LiteralValues

See: JPL-IMCE/gov.nasa.jpl.imce.oml#98

Code generation for OML Tables reader fix

See: JPL-IMCE/gov.nasa.jpl.imce.oml.tables#34

Add support for OML Rules

See JPL-IMCE/gov.nasa.jpl.imce.oml#107

Update code generators for OML AnnotationProperty refactoring

See JPL-IMCE/gov.nasa.jpl.imce.oml#192

Code generation for performance update

See JPL-IMCE/gov.nasa.jpl.imce.oml#260

OML Frameless code generation update.

See JPL-IMCE/gov.nasa.jpl.imce.oml.frameless#8

Add support for OML Rules

See: JPL-IMCE/gov.nasa.jpl.imce.oml#107

Update generated code for special encoding of raw strings

See JPL-IMCE/gov.nasa.jpl.imce.oml#199
See JPL-IMCE/gov.nasa.jpl.imce.oml#205

Code generators for improved type safety of the tabular representation

See JPL-IMCE/gov.nasa.jpl.imce.oml.tables#32
See JPL-IMCE/gov.nasa.jpl.imce.oml.resolver#19

Update generators for the oml.tycho refactoring.

In the cradle-based multi-project organization, there were several git subrepos:

• oml.tables
• oml.resolver
• oml.doc

These were subrepos of the oml.core project so that the gradle build scripts could execute the Xtend generators.

In the tyco-based refactoring, there are no git subrepos.
Instead:

• The Xtend generators are ran from the Eclipse IDE as simple command-line applications.
• The other projects are imported in the Eclipse workspace but are not built in Eclipse.
• The Scala projects (oml.tables and oml.resolver) are developed using IntelliJ.

(IntelliJ uses the SBT build configuration; Eclipse cannot support all the features of the SBT build configuration; which means that to use Eclipse would require maintaining a dual build configuration for a partial build in Eclipse and a complete build in SBT)

ModuleEdge needs to refer to the target module by IRI

To handle arbitrary directed graph topologies of OML Modules & OML ModuleEdges, it is necessary to relax the representation in OML Tables & OML Resolver for a ModuleEdge such that the target Module is referenced by its IRI instead of by its UUID (in the table representation) or by its Module (in the resolver representation).

See JPL-IMCE/gov.nasa.jpl.imce.oml#48

Update code generators for EntityRestrictionAxioms with direction

See JPL-IMCE/gov.nasa.jpl.imce.oml#208

Update for OMLSpecificationTables.read methods

See: JPL-IMCE/gov.nasa.jpl.imce.oml#247

Miscellaneous code generation fixes

See JPL-IMCE/gov.nasa.jpl.imce.oml#256
See JPL-IMCE/gov.nasa.jpl.imce.oml#254
See JPL-IMCE/gov.nasa.jpl.imce.oml#252

Generate frameless reader for OML tabular data

See https://github-fn.jpl.nasa.gov/IMCE/gov.nasa.jpl.imce.oml.spark/issues/1