Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

search for more potential types? #5

Open
steltenpower opened this issue Jun 9, 2022 · 3 comments
Open

search for more potential types? #5

steltenpower opened this issue Jun 9, 2022 · 3 comments
Assignees

Comments

@steltenpower
Copy link
Contributor

Dive into the rabbit hole at https://en.wikipedia.org/wiki/Physical_quantity

@poef
Copy link
Member

poef commented Jun 10, 2022

The current list of types is curated from these sources:

JSON

  • bool
  • number
  • string
  • array
  • object
  • null

PostgreSQL:

  • text
  • int (uint, int8, uint8, int16, uint16, int32, uint32, int64, uint64)
  • float (float32, float64)
  • blob

HTML and CSS:

  • color
  • date
  • email
  • phone
  • url
  • link

RED (https://red-lang.org):

  • uuid
  • money
  • interval

XSD Schema should be in here as well, it has a 'duration' type, which probably should replace the interval type.

But I want to keep the base set of types limited. Similar to how HTML originally had only 20-30 elements. The idea is that it should be easy to write a complete parser/generator for JSONTag. The attributes are meant to add extensibility to the language, without creating incompatible parsers.

As mentioned in #4 I think that points/shapes is potentially useful enough to add in the base set. PostgreSQL has these:

  • point
  • line
  • path
  • polygon
  • box
  • circle

And finally I might want to add a specific type for errors ('error') as that is a vital part of many API's.

@poef
Copy link
Member

poef commented Mar 31, 2023

In line with the email and phone type, an address type sounds reasonable as well. There can be no strict parsing rules for an address type though, since addresses come in so many varieties. Not just postal addresses, but IP addresses should be supported as well. So the tag should probably be defined as an opaque string. You can add an extra class attribute to distinguish between different kind of addresses.

Will this add enough utility to jsontag though? You can also accomplish this by using

<string class="postalAddress">"somewhere"

@poef
Copy link
Member

poef commented Apr 20, 2023

Protocol Buffers also have an extended set of supported types:
"
Duration is a signed, fixed-length span of time, such as 42s.
Timestamp is a point in time independent of any time zone or calendar, such as 2017-01-15T01:30:15.01Z.
Interval is a time interval independent of time zone or calendar, such as 2017-01-15T01:30:15.01Z - 2017-01-16T02:30:15.01Z.
Date is a whole calendar date, such as 2025-09-19.
DayOfWeek is a day of the week, such as Monday.
TimeOfDay is a time of day, such as 10:42:23.
LatLng is a latitude/longitude pair, such as 37.386051 latitude and -122.083855 longitude.
Money is an amount of money with its currency type, such as 42 USD.
PostalAddress is a postal address, such as 1600 Amphitheatre Parkway Mountain View, CA 94043 USA.
Color is a color in the RGBA color space.
Month is a month of the year, such as April.
"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants