View this page "JSON Schema Possible Formats"

[Kris Zyp]

I am working on creating a page for JSON Schema value formats. Feel
free to comment or edit it.

Click on http://groups.google.com/group/json-schema/web/json-schema-possible-formats
- or copy & paste it into your browser's address bar if that doesn't
work.

[Claudio D'Angelo]

How can manage a phone number format?
A phone number can be different (with or without regional prefix, with
or without international prefix, portable phone number, ecc...). How a
parser can validate this information?

[Weston Ruter]

By using a regular expression.

[Kris Zyp]

Well, I didn't really intend for minimal validation to validate formats, I
considered validation on formats is extra credit. Not sure how that should
be stated. Maybe there could be different levels of validation. And, all
format definitions should provide a schema definition for those that do
want to do validation (the phone number currently doesn't, anyone know of
spec to refer to for phone numbers)?
Kris

[Claudio D'Angelo]

I'm thinking that principal scope of schema is to validate a stream.
If this isn't true, at what serve json schema?

I think that a specification must be defined. If there are too many
free hand every implementation develops a system that can't be
portabily.

[Claudio D'Angelo]

OK Weston,
but at what serve the phone type? I use the pattern in a string type.

On Jan 6, 12:18 am, "Weston Ruter" <westonru...@gmail.com> wrote:
> By using a regular expression.
>
> On Jan 5, 2008 12:08 AM, Claudio D'Angelo <
>

[SMM]

Perhaps a regular expression can be used during input to parse the
string, and the phone type itself has a more complex internal
structure which can be formatted on output into a standardized
string. But the data format itself is structured (requiring only
simple validation). For example, the HR-XML schema has a generalized
structure:

http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/ContactMethod.html#_Toc127533181

Stephen

On Jan 6, 11:44 pm, "Claudio D'Angelo" <claudio.dang...@lombardia-

> > > parser can validate this information?- Hide quoted text -
>
> - Show quoted text -

[Claudio D'angelo]

Very well,
but the schema specification must supply the structure for these formats.

SMM ha scritto:

[Kris Zyp]

The whole "format" attribute is really in flux in mind right now. I am
really wondering if I should just drop "format" as a validating attribute ,
and reserve it purely for indicating MIME types, and then use JSON
referencing to utilize shared/common schema definitions. More later on that,
just wanted to let you know what I am thinking.

Kris
----- Original Message -----

[David Waite]

I had a few different ideas:
- time specific
- datetime, date - same as above
- timestamp - offset in seconds since jan 1, 1970 at 12:00
midnight in zulu time, adjusted per UTC rules. May be a
floating point number. similar to utc-millisec, but in
seconds.
- timespan - duration in seconds between two points in
time. May be a floating point number
- timezone - an offset from UTC, eg "UTC+0130"
- zoneinfo - the Area/Location string specifying timezone
rules. See www.twinsun.com--tz-link.htm

- internet address specific
- uri, urn, url - same as above
- ip - a ipv4 (in dot-decimal notation) or ipv6 (rfc4291)
address
- host - an ipv4 or ipv6 address as above, or a domain name
(rfc1034)

- numerical formats
- integer - a number with precision zero (assuming integer is
not a core type)
- nonnegativeint - an int with minimum 0 (includes zero)
- nonnegativefloat - a number with minimum 0 (includes zero)
- digit - the int values zero through nine

- data formats
- base64 a base64-encoded string. Implementations SHOULD
remove whitespace characters

- other formats
- id - a URL fragment identifier string, must be unique within
the document. Similar to HTML anchor names.
- ref - a fragment identifier for id's within the current
document. (Use a URL to reference fragments if you also
want to be able to reference other documents)