Chapter 2: Data Format Deep Dive

Welcome to Chapter 2 of the WIA-IND-012 Fitness Wearable Standard ebook. This chapter explores data format deep dive, providing comprehensive technical insights, implementation examples, and best practices that embody the philosophy of 弘益人間 (Benefit All Humanity).

Introduction

The Fitness Wearable standard represents a critical component of the World Certification Industry Association's comprehensive framework for modern technology standards. As we navigate through this chapter, we'll explore how this standard addresses current industry challenges while paving the way for future innovations.

Building upon the foundational concepts introduced in Chapter 1, this chapter provides a comprehensive deep dive into the data format specifications that form the bedrock of the Fitness Wearable standard. Understanding these formats is crucial for implementing compliant systems that can seamlessly exchange data across platforms and implementations.

Data Format Philosophy

The choice of JSON as the primary data format reflects several key considerations that align with our 弘익人間 philosophy. JSON provides an excellent balance of human readability, machine parse-ability, and broad language support, making it accessible to developers regardless of their technology stack or expertise level.

Unlike binary formats that require specialized tools to inspect, JSON data can be easily examined with basic text editors, facilitating debugging, learning, and transparency. This openness extends to the standard itself - anyone can understand and validate data without proprietary software or complex tooling.

Core Data Structures

The standard defines several core data structures that form the building blocks for all higher-level functionality. Each structure serves a specific purpose while maintaining consistency with overall design principles.

Base Object Structure

Every standard-compliant data object includes a common set of fields that provide essential context and metadata:

{
  "standard": "WIA-IND-012",
  "version": "1.0",
  "philosophy": "弘益人間",
  "id": "uuid-v4-string",
  "timestamp": "2025-01-27T10:30:00.000Z",
  "type": "object-type-identifier",
  "data": {"
}
  },
  "metadata": {
    "created": "2025-01-27T10:30:00.000Z",
    "modified": "2025-01-27T10:30:00.000Z",
    "createdBy": "user-id-or-system-id",
    "source": "application-identifier",
    "version": "object-version-number"
  },
  "extensions": {
    // Optional application-specific fields
  }
}

Field Specifications

Field	Type	Required	Description
standard	string	Yes	Identifies the WIA standard (e.g., "WIA-IND-012")
version	string	Yes	Standard version in semver format (e.g., "1.0")
philosophy	string	Yes	Must be "弘益人間" affirming the guiding principle
id	string (UUID)	Yes	Globally unique identifier (UUID v4)
timestamp	string (ISO 8601)	Yes	UTC timestamp with timezone indicator
type	string	Yes	Object type identifier for routing/processing
data	object	Yes	Type-specific data payload
metadata	object	Yes	Metadata about the object itself
extensions	object	No	Application-specific extensions

Data Type Definitions

The standard supports a rich set of data types, each with specific formatting requirements and validation rules. Understanding these types is essential for creating well-formed, interoperable data.

Primitive Types

Type	JSON Type	Format	Example
String	string	UTF-8 encoded text	"Hello World"
Integer	number	Whole numbers (no decimals)	42
Float	number	Decimal numbers	3.14159
Boolean	boolean	true or false	true
Null	null	Explicit null value	null
Timestamp	string	ISO 8601 with timezone	"2025-01-27T10:30:00.000Z"
UUID	string	UUID v4 format	"550e8400-e29b-41d4-a716-446655440000"

Complex Types

Beyond primitives, the standard defines several complex types for common use cases:

Localized String

{
  "en": "Hello World",
  "ko": "안녕하세요",
  "ja": "こんにちは",
  "default": "en"
}

Geographic Location

{
  "latitude": 37.7749,
  "longitude": -122.4194,
  "altitude": 52.0,
  "accuracy": 10.0,
  "timestamp": "2025-01-27T10:30:00.000Z"
}

Time Range

{
  "start": "2025-01-27T10:00:00.000Z",
  "end": "2025-01-27T11:00:00.000Z",
  "duration": 3600,
  "timezone": "UTC"
}

Validation Rules and Constraints

Proper validation ensures data integrity and system reliability. The standard specifies validation rules at multiple levels:

Field-Level Validation

• Required Fields: Must be present and non-null
• Type Checking: Values must match specified types
• Format Validation: Strings must match specified patterns (e.g., ISO 8601 for timestamps)
• Range Constraints: Numbers must fall within acceptable ranges
• String Length: Minimum and maximum length requirements
• Enumeration: Values must be from predefined sets when specified

Object-Level Validation

• Required Relationships: Certain objects must contain specific related objects
• Conditional Requirements: Some fields become required based on other field values
• Mutual Exclusivity: Certain field combinations are not allowed
• Cross-Field Validation: Values in one field constrain values in another

Encoding and Serialization

Proper encoding ensures data can be transmitted and stored reliably across different systems and platforms:

Character Encoding

All JSON data MUST use UTF-8 encoding without BOM (Byte Order Mark). This ensures consistency across platforms and prevents encoding-related bugs.

Number Precision

Implementations must preserve number precision according to IEEE 754 double-precision floating-point format. Special attention is required for:

• Very large integers (beyond JavaScript's safe integer range)
• High-precision decimal values (financial data, scientific measurements)
• Special values (Infinity, NaN) which should be represented as strings

Date and Time Handling

All timestamps use ISO 8601 format in UTC timezone:

// Correct format
"2025-01-27T10:30:45.123Z"

// Including milliseconds
"2025-01-27T10:30:45.123456Z"  // Microsecond precision

// Date only (time assumed 00:00:00 UTC)
"2025-01-27"

Versioning and Evolution

The standard employs semantic versioning (semver) to manage changes while maintaining compatibility:

Version Change	Compatibility	Examples
Major (1.0 → 2.0)	Breaking changes allowed	Required field changes, type changes
Minor (1.0 → 1.1)	Backward compatible	New optional fields, new object types
Patch (1.0.0 → 1.0.1)	Fully compatible	Documentation clarifications, examples

Migration Strategies

When standards evolve, implementations must handle multiple versions gracefully:

// Version detection and handling
function processData(jsonData) {
  const version = jsonData.version;

  if (version.startsWith('1.')) {
    return processV1Data(jsonData);
  } else if (version.startsWith('2.')) {
    return processV2Data(jsonData);
  } else {
    throw new Error(`Unsupported version: ${version}`);
  }
}

// Version migration
function migrateV1ToV2(v1Data) {
  return {
    ...v1Data,
    version: '2.0',
    // Apply necessary transformations
    newField: deriveFromV1(v1Data)
  };
}

Performance Considerations

While JSON provides many benefits, large datasets require careful optimization:

Compression

JSON data should be compressed for transmission using gzip or brotli. Typical compression ratios:

• gzip: 70-90% size reduction
• brotli: 75-95% size reduction

Streaming

Large datasets benefit from streaming JSON parsers that process data incrementally rather than loading everything into memory.

Binary Alternatives

For high-frequency data transmission, the standard permits Protocol Buffers or MessagePack encodings as alternatives to JSON, provided a JSON representation is available for interoperability.

Best Practices

Common Pitfalls

Understanding common mistakes helps avoid them in your implementation:

Pitfall	Impact	Solution
Incorrect timezone handling	Data appears at wrong times	Always use UTC, convert to local time only for display
Floating-point precision loss	Numeric inaccuracies	Use string representation for high-precision numbers
Missing required fields	Validation failures	Implement comprehensive validation before transmission
Improper character encoding	Garbled text, parsing errors	Enforce UTF-8 encoding throughout the pipeline
Large objects without pagination	Performance problems, timeouts	Implement pagination for collections

With a solid understanding of data formats established in this chapter, we're prepared to explore how these formats are exchanged through standardized APIs in the next chapter. The combination of well-designed data formats and thoughtful API design creates a powerful foundation for interoperable systems that truly benefit all humanity - 弘益人間.