ISSUE-95 PROPOSAL: Clarify the spec. Make a distinction between built-ins and extensions. Stop claiming that built-ins are templates. If an implementation wants to use the template mechanism for built-ins, that's ok but that's not part of the spec.

• From: Arthur Ryman <arthur.ryman@gmail.com>
• Date: Thu, 29 Oct 2015 07:47:53 -0400
• To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
• Message-ID: <CAApBiO=M8BvEZdOg_AOwtbxBJ7HDALeTECJmtGoTAZhi+EptmA@mail.gmail.com>

Finally, the spec still claims that all constraints are either native
or templates. The Glossary says that constraints are: "Are either
native constraints (e.g. based on a SPARQL query) or template
constraints." Is this a leftover? Note that both native constraints
and template constraints require at least one body, e.g. in SPARQL. So
the definition of constraint implies that nothing is built-in. At
best, an implementation can override the body with an optimized
implementation.

Holger is implementing the built-in constraints as templates. However,
the spec makes a distinction between built-ins and extensions.

PROPOSAL: Clarify the spec. Make a distinction between built-ins and
extensions. Stop claiming that built-ins are templates. If an
implementation wants to use the template mechanism for built-ins,
that's ok but that's not part of the spec.

Received on Thursday, 29 October 2015 11:48:24 UTC