# SQL Standard Compliance Critic Framework (ISO/IEC 9075:2023)

This framework guides the Critic role when evaluating SQL code for strict adherence to the SQL:2023 standard (ISO/IEC 9075:2023). This critic focuses exclusively on language specification compliance, standard feature usage, and avoidance of vendor-specific extensions or undefined behavior.

## SQL Standard Compliance Evaluation Areas

### 1. Language Specification Adherence
**What to Look For:**
- Strict adherence to ISO/IEC 9075 (SQL:2023) language specification
- Proper use of standard SQL constructs, data types, and functions
- Avoidance of vendor-specific extensions unless properly guarded
- Correct implementation of language features as defined
- Avoidance of undefined or implementation-dependent behavior

**Common Problems:**
- Use of non-standard SQL extensions without proper abstraction
- Reliance on undefined or implementation-dependent behavior
- Incorrect assumptions about SQL feature support
- Violation of SQL syntax or semantic rules
- Missing or incorrect use of standard data types and constraints

**Evaluation Questions:**
- Does the code conform to the SQL:2023 standard without relying on vendor-specific features?
- Are all standard SQL functions and constructs used correctly according to specification?
- Is undefined or implementation-dependent behavior properly avoided?
- Are vendor-specific features documented and abstracted?
- Does the code execute cleanly on standard-compliant SQL engines?

### 2. Standard Feature Usage
**What to Look For:**
- Correct usage of standard SQL data types (INTEGER, VARCHAR, DATE, etc.)
- Proper implementation of standard functions and operators
- Appropriate use of standard SQL statements (SELECT, INSERT, UPDATE, DELETE)
- Correct syntax for standard SQL clauses (WHERE, GROUP BY, HAVING, ORDER BY)
- Proper use of standard SQL expressions and predicates

**Common Problems:**
- Use of non-standard data types or functions
- Incorrect syntax for standard SQL constructs
- Misuse of standard SQL features
- Assumptions about standard feature behavior
- Missing standard SQL functionality

**Evaluation Questions:**
- Are all data types used from the SQL:2023 standard?
- Are standard SQL functions used correctly according to specification?
- Is the syntax conformant to SQL:2023 grammar?
- Are standard SQL expressions and predicates used properly?
- Does the code avoid non-standard language extensions?

### 3. Implementation Independence
**What to Look For:**
- Code that works across different SQL-compliant database systems
- Avoidance of vendor-specific SQL dialects or extensions
- Use of feature detection or abstraction layers for optional functionality
- Documentation of any implementation dependencies
- Reliance only on standard SQL behavior

**Common Problems:**
- Use of proprietary SQL features without abstraction
- Assumptions about data type sizes or behaviors
- Platform-specific code without proper guards
- Missing feature detection for optional SQL features
- Lack of documentation for implementation dependencies

**Evaluation Questions:**
- Does the code avoid vendor-specific SQL features?
- Are standard data types and constructs used for portability?
- Is platform-specific functionality properly abstracted?
- Are feature detection mechanisms used for optional features?
- Are all implementation dependencies documented?

## ISO/IEC Standards-Specific Criticism Process

### Step 1: Language Compliance Analysis
1. **Check Language Compliance**: Does code conform to SQL:2023 standards?
2. **Evaluate Feature Usage**: Are standard SQL features used correctly?
3. **Assess Undefined Behavior**: Is undefined or implementation-dependent behavior avoided?
4. **Review Vendor Dependencies**: Are vendor-specific features documented and abstracted?

### Step 2: Standard Feature Assessment
1. **Audit Data Types**: Are standard SQL data types used correctly?
2. **Check Function Usage**: Are standard SQL functions used properly?
3. **Evaluate Syntax**: Is the syntax conformant to SQL:2023?
4. **Assess Expressions**: Are standard SQL expressions used correctly?

### Step 3: Implementation Independence Analysis
1. **Check for Vendor Lock-in**: Are vendor-specific features avoided or abstracted?
2. **Evaluate Data Types**: Are standard types used for portability?
3. **Assess Feature Detection**: Are optional features detected and handled?
4. **Review Documentation**: Are dependencies documented?

## ISO/IEC Standards-Specific Criticism Guidelines

### Focus on Specification Compliance
**Good Criticism:**
- "This query uses a vendor-specific extension without abstraction, violating portability requirements."
- "The use of the MERGE statement here does not conform to the SQL:2023 syntax."
- "This function relies on implementation-defined behavior for NULL handling."
- "The data type chosen is not part of the SQL:2023 standard."

**Poor Criticism:**
- "This doesn't look right."
- "This seems non-standard."
- "I don't like this approach."

### Emphasize Standard Conformance
**Good Criticism:**
- "The use of proprietary function X violates SQL:2023 standard compliance."
- "This syntax is not defined in the SQL:2023 specification."
- "The behavior of this construct is implementation-dependent."
- "This feature is not part of the standard SQL language."

**Poor Criticism:**
- "This is non-standard."
- "This might not work everywhere."
- "This is not portable."

## ISO/IEC Standards-Specific Problem Categories

### Standard Compliance Problems
- **Non-Standard Extensions**: Use of vendor-specific features without abstraction
- **Syntax Violations**: Code that does not conform to SQL:2023 syntax
- **Implementation Dependencies**: Unwarranted assumptions about database behavior
- **Feature Misuse**: Incorrect usage of standard SQL features

### Language Specification Problems
- **Invalid Syntax**: Code that violates SQL:2023 grammar rules
- **Undefined Behavior**: Code that relies on implementation-specific behavior
- **Missing Features**: Use of features not defined in the standard
- **Incorrect Semantics**: Misuse of standard SQL constructs

### Implementation Independence Problems
- **Vendor Lock-in**: Use of proprietary features without abstraction
- **Type Assumptions**: Assuming specific data type behaviors
- **Platform-Specific Code**: Unguarded use of platform-specific features
- **Missing Feature Detection**: No checks for optional SQL features

## ISO/IEC Standards-Specific Criticism Templates

### For Standard Compliance Issues
```
Standard Compliance Issue: [Specific standard violation]
Standard Reference: [ISO/IEC 9075 section and paragraph]
Problem: [How this violates the standard specification]
Impact: [Portability, undefined behavior, or non-conformance]
Evidence: [Specific code examples and standard citations]
Priority: [Critical/High/Medium/Low]
```

### For Language Specification Issues
```
Language Specification Issue: [Specific language violation]
Standard Reference: [ISO/IEC 9075 section and paragraph]
Problem: [How this violates the language specification]
Impact: [Syntax error, undefined behavior, or non-conformance]
Evidence: [Specific code examples and grammar rules]
Priority: [Critical/High/Medium/Low]
```

### For Implementation Independence Issues
```
Implementation Independence Issue: [Specific portability problem]
Problem: [What assumptions or dependencies limit portability]
Impact: [Platforms or implementations where this will fail]
Evidence: [Specific code examples and platform differences]
Priority: [High/Medium/Low]
```

## ISO/IEC Standards-Specific Criticism Best Practices

### Do's
- **Cite Standard References**: Always reference specific sections of ISO/IEC 9075
- **Focus on Specification**: Evaluate against the formal SQL language specification
- **Consider All Implementations**: Think about conforming SQL engines, not just one vendor
- **Emphasize Standard Conformance**: Prioritize adherence to the SQL:2023 standard
- **Document Dependencies**: Clearly identify any implementation-defined behaviors

### Don'ts
- **Assume Specific Implementations**: Don't assume particular database behaviors
- **Ignore Standard Features**: Don't overlook proper usage of standard SQL constructs
- **Accept Undefined Behavior**: Don't tolerate code that invokes undefined or implementation-dependent behavior
- **Skip Standard Compliance**: Don't ignore standard conformance requirements
- **Overlook Portability**: Don't accept unnecessarily non-portable code

## ISO/IEC Standards-Specific Criticism Checklist

### Standard Compliance Assessment
- [ ] Does the code conform to SQL:2023 without relying on vendor-specific features?
- [ ] Are all uses of standard SQL constructs correct per specification?
- [ ] Is undefined or implementation-dependent behavior avoided?
- [ ] Are vendor-specific features documented and abstracted?
- [ ] Does the code execute on multiple conforming SQL engines?

### Language Specification Assessment
- [ ] Is the syntax conformant to SQL:2023 grammar?
- [ ] Are standard data types used correctly?
- [ ] Are standard SQL functions used properly?
- [ ] Are standard SQL expressions and predicates used correctly?
- [ ] Does the code avoid non-standard language extensions?

### Implementation Independence Assessment
- [ ] Does the code avoid vendor-specific SQL features?
- [ ] Are standard data types and constructs used for portability?
- [ ] Is platform-specific functionality properly abstracted?
- [ ] Are feature detection mechanisms used for optional features?
- [ ] Are all implementation dependencies documented?

## ISO/IEC Standards-Specific Evaluation Questions

### For Any SQL Code
1. **Does this code conform to the SQL:2023 standard without vendor-specific extensions?**
2. **Are all potential sources of undefined or implementation-dependent behavior eliminated?**
3. **Is the syntax conformant to SQL:2023 grammar rules?**
4. **Are all standard SQL constructs used correctly?**
5. **Is the code portable across conforming SQL engines?**
6. **Are all implementation dependencies documented?**
7. **Does the code avoid non-standard language features?**
8. **Are standard data types and functions used properly?**
9. **Is the code free from vendor-specific assumptions?**
10. **Does the code execute on standard-compliant SQL engines?**

### For SQL Statements
1. **Is the statement syntax conformant to SQL:2023?**
2. **Are all data types used from the standard?**
3. **Are standard SQL functions used correctly?**
4. **Is the behavior defined by the standard?**
5. **Are any vendor-specific features properly abstracted?**

### For Database Schemas
1. **Are all data types from the SQL:2023 standard?**
2. **Are standard SQL constraints used correctly?**
3. **Is the schema definition conformant to the standard?**
4. **Are any vendor-specific features documented?**
5. **Is the schema portable across conforming databases?**

## SQL:2023 Standard Principles Applied

### "Provide a Standard Data Management Language"
- Write SQL code that conforms to the SQL:2023 specification
- Use only standard SQL features and constructs
- Avoid vendor-specific extensions and undefined behavior

### "Ensure Implementation Independence"
- Write code that works across different conforming database systems
- Avoid reliance on vendor-specific behaviors
- Use standard types and constructs for maximum portability

### "Maintain Language Consistency"
- Use standard SQL syntax and semantics consistently
- Follow the formal grammar and specification rules
- Ensure all constructs are used as defined in the standard