You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
phone is already an example (if no abbreviated numbers are used, but only those starting with "+", country code, and the rest), but many more are around:
IBAN (bank account)
EAN
ISBN-13 (book)
DOI (scientific output)
ORCID (researcher ID)
citizen id (BSN in the Netherlands)
passport ID
IPnr
EMEI
and many more
All with their own value constraints e.g. ISBN has a check digit
The text was updated successfully, but these errors were encountered:
As mentioned in #5 I'd like to keep the base set of types limited. But I can see that I haven't created a generic ID type, which may be useful. I could imagine a type like this:
<id class="IBAN">"NO 93 8601 1117947"
The problem here is that it is easy to become confused about the term 'id'. It has many different meanings. There is an id attribute in the spec already, but that is not the same as an id property. This id type would add another level of confusion.
Adding seperate types for each of these is, I think, a bad idea. This would overload the specification and make it much more complex to implement a parser.
For some of these examples, it might be better to use the type address, e.g:
<address class="IP IPv4">"192.168.1.1"
But I do agree that the set of base types is not set in stone, I'd like to get some real world tests done and then evaluate the current selection.
phone is already an example (if no abbreviated numbers are used, but only those starting with "+", country code, and the rest), but many more are around:
IBAN (bank account)
EAN
ISBN-13 (book)
DOI (scientific output)
ORCID (researcher ID)
citizen id (BSN in the Netherlands)
passport ID
IPnr
EMEI
and many more
All with their own value constraints e.g. ISBN has a check digit
The text was updated successfully, but these errors were encountered: