Explain the concepts of core and extended

[webmat]

We need to add an explanation of core and extended in the README.

Here's quick notes of a recent discussion, where I was explaining them:

Q) What's the relationship between base fields and core/extended fields?

So "base" fields don't really have anything to do with the core/extended distinction. Base fields are just named like that because they're at the top level (think @timestamp, message).

What you had in mind with the term "base" is likely what core is.

Q) What's the difference between core and extended fields?

• Core fields are the fields that should be most common across all use cases. They're the most well understood fields of the bunch, so the least likely to change later.
• Extended fields can be just as generally applicable, but perhaps less well understood, or newer concepts. So they have a bit of a higher chance to change later.
• Or in some cases, extended fields may be very well understood, but they're applicable only to a narrow use case. They're not of general interest.
• Different orthogonal criteria can apply, to make a field "extended". In that sense, "extended" is a bit ambiguous.

[MikePaquette]

@webmat Also, "Core" and "Extended" designations are related to #98.

In a nutshell, I propose:

• An implementation can be considered compatible with ECS as long it maps its existing fields to ECS fields.
• An implementation would be considered compliant with ECS only if it also populates as many of the ECS core fields as is practical.

[karenzone]

Does #334 cover this?
From Introduction:

From Converting an Implementation:

[webmat]

I think it does for the most part. Perhaps we could add a section to Q&A about them, laying down more of the points in my initial issue above.

[MikePaquette]

@karenzone can we refer to these as "levels" to be consistent with the actual terms used in the table column header?

"Type" is becoming overloaded in ECS, for example, with event.type and the Elasticsearch field datatype (which uses "Type" as its column header) - Maybe we should fix that, too?

[webmat]

Good point.

Note that for the Elasticsearch data types, we should use the term of the Elasticsearch documentation: datatype

As for these headings, you're right that we should avoid the use of the word "type". Close to what you're suggesting, what about the expression "field levels"?

[jamiehynds]

Closing as our docs include explanation of core and extended fields.