SchemaPatterns

This is a discussion of changing the terminology from section 2.1 of the Syntax document.

The Syntax document distinguishes between top-level Atom elements as "entities" and Atom elements that can't contain other elements as "properties".

• JeremyGray has rightly suggested that using the term "entity" in this context is a direct conflict with XML's concept of entities. He suggested calling Atom entities "Resources, Constructs, etc." instead.

• It appears that the "construct" label has stuck, but is it optimal?

• RichHall has pointed out it could be more consistent with OOP to change the names of the SchemaPatterns from "entity-property" to "object-property" in reference to syntax, and then refer to objects as "records" and properties as "fields" in the context of database implementations.

There are pros and cons to the object-property / record-field terminology as opposed to entity-property or construct-property:

Pros

• Doesn't conflict with XML terminology

• More familiar to most programmers

• Helps relate XML schema to DB schema while allowing them to be discussed separately

• Can effortlessly suggest a standardized implementation of an Object Model or database schema that complements the XML syntax.

Cons

• Might suggest an unintended standardization of an Object Model or database schema.

• Doesn't have construct's groovy Matrix movie connotations.

Comments

[JeremyGray] We should probably take care to not use the word "entity" in this context, as it overlaps with existing terminology. A couple of potential replacements off the top of my head (not saying that they are good, however): Resource, Construct, mind's drawing a blank right now... Where's my Red Bull?

[RichHall] It could be more consistent with OOP to change the names of the SchemaPatterns from "entity-property" to "object-property" in reference to syntax, and then refer to objects as "records" and properties as "fields" in the context of database implementations.

[KenMacLeod] I originally used "entity" in the DB sense. Feel free to substitute any similar term.

CategorySyntax