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.

Sign up for GitHub

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

Discourage use of fragment in URI #1100

Merged
merged 3 commits into from
Sep 10, 2018
Merged

Discourage use of fragment in URI #1100

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2131bab
Refine URI reqs
lexaknyazev Sep 13, 2017
5d30f0a
Rewrite URI section
lexaknyazev Sep 14, 2017
22fcde4
Refine Relative references description
lexaknyazev Sep 15, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions specification/2.0/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,11 +179,13 @@ To simplify client-side implementation, glTF has following restrictions on JSON

## URIs

glTF uses URIs to reference buffers and image resources. These URIs may point to external resources or be data URIs that embed resources in the JSON. Embedded resources use "data" URI scheme ([RFC2397](https://tools.ietf.org/html/rfc2397)).

> **Implementation Note:** Data URIs could be [decoded with JavaScript](https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding) or consumed directly by web browsers in HTML tags.
glTF uses URIs to reference buffers and image resources. Clients must support at least these two URI types:

- **Data URIs** that embed resources in the JSON. They use syntax defined by [RFC 2397](https://tools.ietf.org/html/rfc2397).
> **Implementation Note:** Data URIs could be [decoded with JavaScript](https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding) or consumed directly by web browsers in HTML tags.

Client implementations are required to support only embedded resources and relative external references (in a sense of [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2)). Clients are free to support other schemes (such as `http://`) depending on expected usage.
- **Relative URI paths** — or `path-noscheme` as defined by RFC 3986, [Section 4.2](https://tools.ietf.org/html/rfc3986#section-4.2) — without scheme, authority, or parameters. Reserved characters must be percent-encoded, per RFC 3986, [Section 2.2](https://tools.ietf.org/html/rfc3986#section-2.2).
> **Implementation Note:** Clients can optionally support additional URI components. For example `http://` or `file://` schemes, authorities/hostnames, absolute paths, and query or fragment parameters. Assets containing these additional URI components may be less portable.

> **Implementation Note:** This allows the application to decide the best approach for delivery: if different assets share many of the same geometries, animations, or textures, separate files may be preferred to reduce the total amount of data requested. With separate files, applications can progressively load data and do not need to load data for parts of a model that are not visible. If an application cares more about single-file deployment, embedding data may be preferred even though it increases the overall size due to base64 encoding and does not support progressive or on-demand loading. Alternatively, an asset could use GLB container to store JSON and binary data in one file without base64 encoding. See [GLB File Format Specification](#glb-file-format-specification) for details.

Expand Down