Use of Standards - bounswe/bounswe2026group9 GitHub Wiki

In Social Event Mapper, standards are important because the system is built around structured event data, time-sensitive workflows, map-based discovery, and interactive web/mobile clients. Instead of defining everything in a project-specific way, we chose widely accepted standards that improve interoperability, consistency, accessibility, and maintainability.

This page explains the standards that are most relevant to our project, why we selected them, and how we plan to integrate them into the system.

1. RFC 3339 / ISO 8601 for Date and Time Representation

Which standard was selected?

We selected RFC 3339 / ISO 8601 as the standard for representing date and time values in our system.

Relevant standard terms / structures

  • YYYY-MM-DD
  • YYYY-MM-DDTHH:MM:SSZ
  • timezone-aware timestamps
  • UTC offsets such as +03:00

Why was it chosen?

Social Event Mapper is an event-centered platform, so date and time consistency is critical. Event creation, discovery filtering, event lifecycle tracking, notifications, and mobile/web synchronization all depend on start and end times being represented in a reliable and unambiguous format.

Using a standard format prevents problems such as:

  • timezone confusion
  • inconsistent parsing between frontend, backend, and mobile
  • incorrect filtering of upcoming or past events
  • invalid comparisons between start and end times

How do we plan to integrate it into our system?

This standard is already closely aligned with our current implementation.
We use ISO-style timestamps for:

  • event start_datetime
  • event end_datetime
  • created_at
  • updated_at

The backend validates and processes event datetimes using standard timestamp handling, and frontend/mobile clients exchange these values as machine-readable strings. These timestamps are then formatted only for display on the client side.

This means RFC 3339 / ISO 8601 acts as the common time representation standard across all layers of the project.

2. OpenAPI 3.1 for API Description

Which standard was selected?

We selected OpenAPI 3.1 as the API description standard for our backend services.

Relevant standard terms / structures

  • paths
  • components
  • schemas
  • requestBody
  • responses
  • parameters
  • securitySchemes

Why was it chosen?

Social Event Mapper has a multi-client architecture:

  • a backend API
  • a web frontend
  • a mobile application

Because these parts exchange the same event, user, notification, bookmark, comment, and rating data, the system benefits from having a standard API contract.

OpenAPI is useful because it:

  • makes backend endpoints self-describing
  • improves communication between backend, frontend, and mobile developers
  • makes testing and debugging easier
  • provides a standard documentation format instead of ad hoc endpoint notes

How do we plan to integrate it into our system?

Our backend is implemented with FastAPI, which already supports OpenAPI-based API documentation. We plan to continue using this standard as the formal contract for our HTTP API.

This includes documenting endpoints such as:

  • authentication
  • event creation and editing
  • discovery listing
  • comments
  • notifications
  • attendance and bookmarks
  • profile and rating actions

In practice, OpenAPI helps ensure that all clients interpret backend responses and request payloads consistently.

3. WCAG 2.1 / 2.2 and WAI-ARIA for Accessibility

Which standard was selected?

We selected WCAG 2.1 / 2.2 and WAI-ARIA as accessibility-related standards for the web application.

Relevant standard terms / structures

  • semantic HTML
  • keyboard accessibility
  • visible focus states
  • aria-label
  • aria-hidden
  • aria-expanded
  • aria-checked
  • role="switch"
  • accessible form labeling

Why was it chosen?

Social Event Mapper contains many interactive components, such as:

  • event cards
  • map/list view toggles
  • filters
  • drawers and modals
  • event creation forms
  • image carousels
  • notification panels
  • profile settings controls
  • comments and replies

These features should not only look good visually, but also be usable by keyboard users and assistive technologies such as screen readers. Accessibility standards improve:

  • usability
  • inclusivity
  • interface clarity
  • consistency of user interaction

They also help make the project more professional and standards-compliant.

How do we plan to integrate it into our system?

Our current web implementation already includes some accessibility-aware practices such as:

  • aria-label usage for icon-only buttons
  • focus-visible states for interactive controls
  • switch-like semantics for profile settings
  • accessible labels for carousel navigation and filters

We plan to strengthen this further by continuing to apply WCAG and ARIA principles to:

  • event discovery filters
  • navigation drawers
  • map/list switching
  • create/edit event forms
  • notifications
  • comments and profile interactions

This standard is especially important for our web interface because the application contains many stateful and interactive UI elements.

4. JSON-LD 1.1 with Schema.org Vocabulary

Which standard was selected?

We selected JSON-LD 1.1 as the structured data format and Schema.org as the vocabulary for describing public event and profile data.

Relevant standard terms / structures

  • @context
  • @type
  • Event
  • Person
  • Place
  • GeoCoordinates
  • AggregateRating
  • name
  • description
  • startDate
  • endDate
  • location
  • organizer
  • image
  • url
  • eventStatus

Why was it chosen?

Our project includes public event pages and public host profile pages. These pages are not just user interfaces; they also represent structured real-world entities:

  • events
  • people
  • places
  • ratings

Schema.org already provides a standard vocabulary for these concepts, and JSON-LD provides a clean machine-readable way to embed them into webpages.

This is beneficial because it:

  • makes public content easier for machines to interpret
  • improves interoperability with search engines and external systems
  • gives us a standard representation of event and host metadata
  • avoids inventing custom, non-standard metadata formats

How do we plan to integrate it into our system?

This is the standard we plan to integrate most explicitly on the frontend side.

We plan to add JSON-LD blocks to:

  • public event detail pages
  • public host profile pages

For event pages, our event data can be mapped to Schema.org Event, using fields such as:

  • event title -> name
  • description -> description
  • start and end timestamps -> startDate, endDate
  • host -> organizer
  • venue/location -> location
  • event image -> image

For host profile pages, we can use Schema.org Person with:

  • host username/name
  • host image
  • public profile URL
  • AggregateRating for host ratings

Because our project also includes private events, we would apply this carefully:

  • public events can expose structured metadata
  • private events should expose only limited or no public structured data depending on visibility rules

This makes JSON-LD + Schema.org a very good semantic-web standard for our project without requiring major backend redesign.

Conclusion

The standards selected for Social Event Mapper were chosen because they directly match the needs of our system:

  • RFC 3339 / ISO 8601 ensures consistent date-time handling across backend, web, and mobile.
  • OpenAPI 3.1 provides a standard API contract for our multi-client architecture.
  • WCAG 2.1 / 2.2 and WAI-ARIA improve accessibility and usability in our interactive web interface.
  • JSON-LD 1.1 with Schema.org provides a standard semantic representation for public event and host data.

These standards help us build a system that is more reliable, understandable, accessible, and maintainable.