Use of Standards

Use of Standards

1. GeoJSON (RFC 7946)

What it is: An open standard format for encoding geographic data structures using JSON.

Where we use it:

• The /api/obstacles endpoint returns obstacle locations as GeoJSON-compatible coordinate pairs (latitude, longitude).
• The /api/routes/calculate endpoint uses Valhalla, which encodes route shapes as polylines — we decode these into [lat, lng] waypoint arrays matching GeoJSON coordinate conventions.
• The frontend map component (MapView.tsx) renders markers and route lines using these coordinates via a Leaflet WebView.

Why this standard: GeoJSON is the de facto standard for geospatial data on the web. It ensures interoperability with mapping libraries (Leaflet, Mapbox) and external routing APIs (Valhalla, OpenRouteService) without custom transformation layers.

---

2. Schema.org Structured Vocabulary

What it is: A collaborative community activity that creates and maintains schemas for structured data on the internet.

Where we use it:

• Report entities map to schema:LocalBusiness / schema:Place concepts — specifically schema:location (lat/lng), schema:name (title), and schema:description.
• User profiles follow schema:Person with fields like schema:name (fullName) and schema:birthDate.
• Obstacle categories (ramp, elevator, stairs, etc.) align with schema:accessibilityFeature and schema:accessibilityHazard properties from Schema.org.

Why this standard: Using Schema.org vocabulary keeps our domain model aligned with widely understood semantics, making the API more self-documenting and ready for future semantic web or search indexing use cases.

---

3. W3C WCAG 2.1 (Web Content Accessibility Guidelines)

What it is: The W3C standard defining how to make web and mobile content accessible to people with disabilities.

Where we use it:

• The entire project is built around accessibility for mobility-impaired users. Route calculations use the OpenRouteService wheelchair profile, which avoids stairs, steep slopes, and inaccessible surfaces — directly implementing the spirit of WCAG Success Criterion 1.3.4 (physical accessibility).
• The obstacle reporting system allows users to report inaccessible infrastructure (missing ramps, broken elevators), contributing to a community-maintained accessibility map.
• The mobilityProfile stored per user (mobility aid type, additional needs) allows the app to personalize routing — a form of adaptive presentation per WCAG Guideline 1.3 (Adaptable).
• Frontend uses sufficient color contrast and touch target sizing for motor-impaired users.

Why this standard: Our target users are people with mobility impairments. WCAG 2.1 is the internationally recognized benchmark for accessibility compliance and shapes both our routing logic and UI decisions.

---

4. RFC 7519 — JSON Web Tokens (JWT)

What it is: An open standard (IETF RFC 7519) that defines a compact, self-contained way to securely transmit information between parties as a JSON object.

Where we use it:

• All authenticated API endpoints require a Bearer <token> JWT in the Authorization header.
• We use djangorestframework-simplejwt which fully implements RFC 7519.
• Access tokens expire in 30 minutes; refresh tokens expire in 7 days, with rotation and blacklisting enabled (old refresh tokens are invalidated on use).
• Token claims include standard fields: iss, sub (user ID), iat, exp.

Why this standard: JWT is stateless — the server doesn't need to store session data. This makes our API horizontally scalable. The standard's wide adoption means frontend clients (React Native) and backend (Django) have mature library support with no custom crypto code required.

---

5. ISO 8601 — Date and Time Format

What it is: The international standard for representing dates and times (e.g., 2026-04-06T14:30:00Z).

Where we use it:

• All timestamps returned by the API (createdAt, updatedAt, birthDate) are serialized in ISO 8601 format by Django REST Framework's DateTimeField and DateField.
• JWT iat and exp claims use Unix timestamps (seconds since epoch), which is ISO 8601-compatible per RFC 7519.
• The UserProfileSerializer serializes birthDate as YYYY-MM-DD (ISO 8601 date format).

Why this standard: ISO 8601 is unambiguous across locales and time zones. Using it prevents date parsing bugs between the Django backend (UTC), the React Native frontend, and any third-party integrations. It is also the default for DRF serializers, reducing custom configuration.