http://opengeoportal.org/software/metadata-toolkit/
I think they're also developing using Ruby, targeting ISO19115-1 content, @chrissbarnett is one of the lead developers. They demo'd the online editor yesterday in a telecom that was recorded, the web page hasn't been updated recently. Maybe can save some dev effort on the mdEditor here?

Add to CONTRIBUTING.md or create STYLEGUIDE.md and refer to that in the documentation section. Mainly we need to specify the rules concerning documenting components, services, helpers, etc. using modules.

Add spatial extent component that supports:

• manual creation of mapping extents(points, lines, polygons) as GeoJSON features
• import of shapefile(zip), geoJSON, kml, etc. by drag-n-drop or upload field
• editing geoJSON feature properties in object table

Working Demo with this feature: https://jlblcc.github.io/mdEditor

This may be a good candidate for stand-alone add-on.

Available add-ons/libs:

• http://www.ember-leaflet.com/
• https://github.com/canufeel/ember-leaflet-layer-control
• https://github.com/calvinmetcalf/leaflet.shapefile or https://github.com/mbostock/shapefile
• https://github.com/makinacorpus/Leaflet.FileLayer
• https://github.com/mapbox/togeojson
• https://github.com/mapbox/leaflet-omnivore
• https://github.com/calvinmetcalf/leaflet.filegdb
• https://github.com/Leaflet/Leaflet.draw or https://github.com/Leaflet/Leaflet.Editable
• https://github.com/onechiporenko/ember-models-table
• https://github.com/mike-north/ember-resize

Requires:

• Bootstrap: bower install bootstrap-sass
  • ScrollSpy requires a fix like this
  • breadcrumbs
• SASS: ember-cli-sass
• Font Awesome: ember-cli-font-awesome
• https://silviomoreto.github.io/bootstrap-select/examples/ (replaces selectize)
• Tour: rwwagner90/ember-shepherd or sorich87/bootstrap-tour

See http://arcticlcc.github.io/mdeditor-layout/

Stringified code is being inserted!??

Add in app/pods/{record type}/new

• new contact
• new dictionary
• new record

note: Requires feature 29

This will make it easy to deploy the demo to GitHub pages @ http://www.adiwg.org/mdEditor.

Note that we must use the hash locationType when deploying to GitHub pages, see the docs.

We use YUIDoc for the API documentation. We need a better theme and structure for documenting the API than the default one. Here's a starting point: https://github.com/offirgolan/yuidoc-ember-theme

https://github.com/ember-cli/ember-cli/releases/tag/v2.11.1

This is a list of tests that need to be created or updated.

Services

• icon
• profile

Adapters

• application (updateRecord)

Components

• md-help (not yet fully implemented)

Routes*

• import
• export

*Probably should handle these in the acceptance tests, unless they have actions.

Addons (in-repo)

• ember-leaflet-table
• ember-json-tree

• Import
  • single record*
  • all records*
  • zip archive with all data
• Export
  • single record*
  • all records*
  • zip archive with all data

*Record = mdJson, contact, or dictionary

Should we change the license to one that requires open sourcing of distributed contributions? That is, the GPL. See http://choosealicense.com/ for reference.

Using JSON API looks like a good approach. Ember supports it. It also is supported by the ember-local-storage addon (plus it would allow for switching to the JSONAPIAdapter if using a server for persistence).

The meta property could be used to store general mdEditor config data. Re: profiles, one approach would be to store any used profile in meta, assign ids, and reference the profile by id in the record (similar to how contact[ ] works in mdJSON). This would avoid storing the profile multiple times, once per record.

We need to decide how to store entities that exist outside of a record, currently contacts and dictionaries. Store them separately in localstorage? Regardless, we'll need a way to reference them within the record store. Since we're trying to keep the mdJSON intact(right?) within localstorage, we'll need to embed them into each record. It might make sense to use the relationships property in JSON API to make tracking dependency on these "external" entities easier.

See: https://www2.usgs.gov/science/about/

In /pods/components/object

• md-address
• md-authority
• md-citation
• md-dates
• md-date
• md-datetime
• md-identifiers
• md-online-resources
• md-phones
• md-responsible-parties
• md-table

Note: Requires feature 29

I suggest we adopt a Forking with feature branches workflow. I borrowed from various sources, but primarily from here. The rest originated from my own damaged brain:

Branching model

Distinguishes four types of branches:

master – main branch: only fully stable, working releases

release – branch serving as a testing space before releases

develop – this is the place where all development happens

feature/fix/hotfix-branches – a single branch which can be created by any developer, which is responsible for new features, fixes or reported bugs. Every feature branch name should start with the proper prefix and be named after the corresponding issue with the appropriate label. Branch names should follow the following format: {prefix}-{issue number}-{descriptive-name}. The {descriptive-name} doesn't need to match the issue name exactly(keep it short), but I should convey the purpose of the branch.

Examples:

• release: release-v0.9.1
• feature: feature-11-contact-component
• fix: fix-12-new-contact-action
• hotfix: hotfix-13-fatal-crash

Creating new branches

New branches _must_ be created from develop. Branches may be created either by forking, or in the main repo (if you have permissions). Forking is recommended, especially for minor or experimental features. Core feature branches may be created in the main repo to ease collaboration. NOTE: An exception is made for _critical_ hotfix branches - they may be diverged from master, but must be merged into both master and develop.

Develop, Release, and Master

Develop

Branch on which the main development happens. New feature/fix branches must be created from develop. Feature branch pull requests must be made against develop. It is recommended to rebase the feature branch to clean/fix/squash unnecessary commits prior to any pull request. Merge conflicts must be resolved by the branch owner (or person issuing pull request).

Release

Branches used for testing before releasing. Release branches are diverged from the develop branch. Release branches constitute a "feature-freeze". Any bugs may be fixed via pull request using fix branches created from the newest release branch. However, changes must be synced back to develop.

Master

The main branch that contains only fully stable, already released iterations of project. Accepts merges from the latest release branch only. Every merge to master must be properly tagged.

Unit Tests

Branches must include tests for new functionality and pass(or update) existing tests before Pull Requests will be accepted.

Deleting branches

Branches merged into master or develop will be deleted from the main repository. An exception is made to maintain branches for the last version of major releases so that bug fixes may be applied. "Stale" branches will be reviewed after minor releases and deleted if no longer relevant.

Milestone and Issue Tracking

GitHub is used for issue tracking. Accepted "bug" or "enhancement" issues must be assigned an appropriate milestone and tag[fix|hotfix|feature]. Semantic versioning is used for Milestones and corresponding Release Tags.

Issues should be closed by a feature branch via a commit message or pull request.

The goal is to generate changelogs from closed issues related to a milestone.

Commit Messages

See this post from chris.beams.io. Summarized below:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

See: https://guides.emberjs.com/v2.6.0/routing/defining-your-routes/#toc_wildcard-globbing-routes

See https://github.com/ember-animation/liquid-fire

it all looks like ember framework stuff... Which branch should I be looking at?

Should we add a profile route with descriptions of use?

/pods/components/input

• md-boolean
• md-codelist-multi
• md-codelist
• md-datetime
• md-select (was object-single)
• md-inputs (was input-text-array)
• md-input (was input-text)
• md-textarea

ember-power-select-with-create might be a better long-term solution. ember-power-select is well supported and this just adds the create option. ember-power-select comes with a Bootstrap theme.

We'll need a way to support long lists of keywords. It seems the best way would be to have a "tree" representation of the list. Should be implemented initially as in-repo addon. Possible requirements:

• POJO objects
  • Ember Data support?
  • Lazy-loading via AJAX?
• Support multiple keyword sections
• Searchable
• Keyword definitions
• Ability to choose between hierarchy or individual keywords
• Choose hierarchy separator character
• Drag-n-Drop
• Support remote lists from a webservice

Possible inspiration: http://gcmd.arcticlcc.org/

Related addons:

• https://github.com/btecu/ember-simple-tree
• https://github.com/mharris717/ember-drag-drop

Using funkensturm/ember-local-storage

• use as application default storage, any non-local storage types will need to overrride as-needed
• add Adapter & Serializer
• add JSON transform

Something like this (could use the version instead when we have a release):

li.sidebar-brand::after {
    content: 'dev';
    color: orange;
    font-variant: small-caps;
    font-size: .75em;
    position: relative;
    top: -7px;
}

This would enable rich-text input in properties like abstract, but still be readable when output as plain text. Another benefit is that rendering in a markdown parser would not mangle non-markdown(ed) text blocks.

https://github.com/NextStepWebs/simplemde-markdown-editor looks like a good candidate. There's a basic addon for ember: ember-simplemde or we could roll our own component.

Do we need to keep any of the "prototyping" branches besides dictionary?

https://github.com/miguelcobain/ember-leaflet/releases

Add md-object-contacts and any sub-components needed to support contacts.

In: pods/components/object/md-contact

Modules:

• md-contact

Add in app/pods/{record type}

• contacts dashboard
• dictionaries dashboard
• records dashboard

Note: Requires feature 32

List of ideas for record profiles:

• Full
• Basic
• Data Product
• Project
• Spatial (Vector)
• Spatial (Gridded)
• Spatial (Imagery)
• Tabular (Flat, Spreadsheet)
• Tabular (Database)
• Biological Profile
• Data Collection
• Software

This is the method I wrote to clean the JSON. Am I missing anything? It's set to retain the empty arrays at the root (configurable). Blows away everything else, including empty objects and arrays, null, undefined, empty strings. Uses isBlank, so it kills strings with only whitespace, too. I considered allowing null, but the schemas only allow it in the GeoJSON - so it shouldn't ever be an issue.

https://ember-twiddle.com/94abb3135cfaaa30ab04655809fa199c

We'll need to implement some sort of ScrollSpy-like functionality for the section menus. See screenshot below for example.

There is ember-strap which we can probably steal from - if it still works (code).

However, we might want to roll our own component if the routing's going to be a pain.

UI Mockup:

The "Add Keywords" button actually adds a new thesaurus. This may be confusing to some users. Recommend renaming to "New Thesaurus" or "Add Thesaurus".

Moved to #83

Hi,

I have installed mdEditor (App Version: 0.0.0+2c2ea582) on Ubuntu 16-04. The install seemed to succeed, however when accessing the application, no metadata fields are visible (see screen cap). A warning message is presented in the console, but it does not seem to be related:

vendor.js:17266DEPRECATION: ember-getowner-polyfill is now a true polyfill. Use Ember.getOwner directly instead of importing from ember-getowner-polyfill [deprecation id: ember-getowner-polyfill.import]
at logDeprecationStackTrace (http://localhost:4200/assets/vendor.js:17248:19)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:17358:7)
at raiseOnDeprecation (http://localhost:4200/assets/vendor.js:17278:12)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:17358:7)
at invoke (http://localhost:4200/assets/vendor.js:17374:7)
at deprecate (http://localhost:4200/assets/vendor.js:17342:32)
at Object.deprecate (http://localhost:4200/assets/vendor.js:30207:37)
at Module.callback (http://localhost:4200/assets/vendor.js:159591:21)
at Module.exports (http://localhost:4200/assets/vendor.js:140:32)

I am having the same experience with a local install on Mac OS X 10.11.6

Have you seen similar behavior? Thoughts on possible causes or troubleshooting approaches?

This will allow us to define tooltips in templates and remove the calls to didInsertElement. Suggest using the ember-tooltips addon.

adiwg/mdCodes will be used in various places in the editor, mostly for input lists. The required codelist(s) should be pre-loaded and made available as a service.

The contacts model & components need to be updated to be compatible with mdJSON 2.0.

• In 2.0 there is only one schema for both types of contacts. The required isOrganization property determines the type of contact.
• Rules for name have changed, see mdTools
• positionName will only be valid for individual contacts.
• It's now possible to assign contacts to an organization
• Support was added for logos
• Address is now an array
• phoneBook changed to phone
• hoursOfService was added as an array of character strings.
• contactType was added as a user defined contact type (might want to have this as an editable select).
• electronicMailAddress is an array of strings. It was moved to the base of 'contact' from 'address'.
• contactInstructions added

Refer to adiwg/mdJson-schemas/issues/48.

Possibly add entry of point, line, or poly to contacts to represent the location of a contact (person or org).

Should we consider adding a production error tracking service? This will probably be more important as we near a release candidate. Some possibilities are:

• https://sentry.io/for/open-source/ (free & open source service option)
• https://www.honeybadger.io/ (free for open source)
• https://trackjs.com/ (possible open source sponsorship)
• https://rollbar.com/
• https://www.stacksentinel.com/

Issues we have been having with ember-cli-selectize have prompted us to try another select list addon. We are hoping that the greater access select2 provides to the HTML will allow us to accomplish some of the more complex features we envision.

• https://select2.github.io/select2/select2
• https://fk.github.io/select2-bootstrap-css/3.5.3.html

So far we have tried ...

• power-select
• ember-cli-selectize
• ember-cli-selectize-drowdown

Main Nav (Routes only)

• Dashboard (default route)
• Save*
• Import*
• Translate*
• Publish*
• Help

_Resources_ with nested routes

• records list all records
  • new create a new record
  • {id} not a route!
    • /show show the summary for the record
    • /edit edit the record
    • /keywords
    • /spatial
    • /quality
    • /distribution
    • /associated
    • /documents
    • /dictionaries**
    • /coverages
    • /grid
• contacts
  • new
  • {id} not a route!
    • /show show the summary for the record
    • /edit
• dictionaries
  • new
  • {id} not a route!
    • /show show the summary for the record
    • edit
    • domains
    • entities

* Not sure we need routes for these. Will each one have a "page" or be handled in modal pop-up? Maybe both? Pop-up for current record, plus a "dashboard-type" layout for batch actions.

** May not need a route if we can squeeze into another layout. Especially since dicts are managed separately.

Loading/Population of mdEditor

• User loads an existing metadata record (partial or complete) into the online mdEditor by browsing from their local machine. Input file format = ADIWG JSON.
• User loads an existing metadata record (partial or complete) into the online mdEditor by browsing from their local machine. Input file format = ISO-19115-2 xml.
• User loads an existing metadata record (partial or complete) into the online mdEditor by browsing from their local machine. Input file format = ScienceBase JSON.

Output of mdEditor

• User can complete a metadata record in the mdEditor and save/export a stand-alone metadata file to their local system. Output file format = ISO-19115-2 xml.
• User can complete a metadata record in the mdEditor and save/export a stand-alone metadata file to their local system. Output file format = ADIWG JSON.

General Use Experience

• mdEditor designed/laid out in such a way where optional or potentially more complex sections are collapsed until toggled. Required elements and those that are the most important for a usable/useful record are emphasized via GUI real estate allocation and layout design.
• Default element values within the mdEditor form are present or available where appropriate.
• Help tips to inform users how particular elements in the mdEditor should be populated and which are mandatory are present for different fields/sections of the form.
• User can dynamically validate their metadata record in the mdEditor against the ADIWG JSON schema to assess for completeness/compliance as they add/edit content.
• Dynamic error reporting is JSON element specific (where is the error occurring?) and tool may provide additional tips or a link to documentation to understand how particular elements should be populated.
• Keyword web services (or static hard-coded Controlled Vocabularies) are available for use within the tool when populating place/theme keywords.
• USGS individuals have ‘auto-import’ contact feature available to pull in their contact details (P. Schweitzer’s resource could most likely be used for this).

User Login/Power User Options/Extended Possible Features

• mdEditor allows a user to ‘save’ and return at a later point to continue editing a record in the form.
• Offline version of tool as stand-alone?
• User loads an existing metadata record (partial or complete) into the online mdEditor by browsing from their local machine. Input file format = FGDC-CSDGM (content populated may be <100%-- only map-able elements ingested).
• User can complete a metadata record in the mdEditor and save/export a stand-alone metadata file to their local system. Output file format = FGDC-CSDGM (content populated may be <100%-- only map-able elements exported).
• Ingest routines with input file in format other than ADIWG JSON generate report that identifies which elements were not mapped/transferred.
• Taxonomic section ‘auto build’ from ITIS service?
• Tool provides feature to auto-build spatial reference/extent section of ADIWG JSON record? A user points to an ESRI supported dataset and .prj and spatial extent are read in and written into the correct elements/structure.

Though I would start a conversation about how to handle deleting contacts...

I see a check box on the contact tab operating similar to a 'show hidden' switch. This would flip from a 'show all' to 'show for resource'.

Resource contacts can NOT be deleted, only removed.

Contacts can be deleted from 'show all' but a search needs to be preformed before deleting. But search what? The open resource? All loaded resources?

We will definitely need a method of handling orphaned responsibleParties. Loading the contact block when saving the record might cover most cases. When loading the resource missing contacts could be restored. For this to work we would need to load the mdJson contact block on saving, but also on switching between resources.

All this same-same for dictionaries.

I suggest we take a look at the following:

https://github.com/emberjs/ember.js/blob/master/STYLEGUIDE.md
https://github.com/softlayer/ember-style-guide

There are some differences, so I would use the official Emberjs guide as the default and merge in the softlayer one (which is more comprehensive).

One big difference is the whitespace. I prefer the Emberjs rule: Use soft tabs set to 2 spaces.

We'll need to upgrade the ember-json-tree in-repo addon with a few enhancements to support a taxonomy component. This is what I think we'll need:

• tree-form component, for editing leaf object details
• create, delete, move up, move down leaf actions
• drag-n-drop leaf (optional)
• multiple deletion (optional)

Ideally, we can hook into the ITIS API for the taxonomic component and allow searches by common, scientific, or TSN. That will be implemented separately from ember-json-tree.