src#cube#sometag<br>#-sky&-rain<br>#-language&english<br>#price=>5<br>https://linux.org/penguin.png`
https://linux.world/distrowatch.gltf#t=1,100linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_applyandroidapp://page1?tutorial#pos=0,0,1&t1,100foo.mp3#0,0,0#cube#sometag<br>#-sky&-rain<br>#-language&english<br>#price=>5<br>https://linux.org/penguin.png`https://linux.world/distrowatch.gltf#t=1,100linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_applyandroidapp://page1?tutorial#room1&t1,100foo.mp3#0,0,0aquariumcube
hrefstring (uri or predefined view)
-#room1
#pos=room1&rot=90,0,0
://somefile.gltf#room1
#room1
#room1&rot=90,0,0
://somefile.gltf#room1
@@ -1593,9 +1593,9 @@ If a glTF implementation does not support a particular extension, the (XRF) extr
-Example 1 In case of the OMI_LINK glTF extension (href: https://nlnet.nl) and an XR Fragment (href: #pos=otherroom or href: otherplanet.glb), it is clear that https://nlnet.nl should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (#pos= e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
+Example 1 In case of the OMI_LINK glTF extension (href: https://nlnet.nl) and an XR Fragment (href: #otherroom or href: otherplanet.glb), it is clear that https://nlnet.nl should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (#room1 e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
-Example 2 If an Extensions uses XR Fragments in URI’s (href: #pos=otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
+Example 2 If an Extensions uses XR Fragments in URI’s (href: #otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
Vendor Prefixes
diff --git a/doc/RFC_XR_Fragments.md b/doc/RFC_XR_Fragments.md
index 38de5ab..94eaf15 100644
--- a/doc/RFC_XR_Fragments.md
+++ b/doc/RFC_XR_Fragments.md
@@ -506,7 +506,7 @@ It instances content (in objects) in the current scene/asset, and follows simila
| fragment | type | example value |
|----------|------|---------------|
-|`src`| string (uri, hashtag/filter) | `#cube`
`#sometag`
#cube&-ball_inside_cube`
`#-sky&-rain`
`#-language&english`
`#price=>5`
`https://linux.org/penguin.png`
`https://linux.world/distrowatch.gltf#t=1,100`
`linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply`
`androidapp://page1?tutorial#pos=0,0,1&t1,100`
`foo.mp3#0,0,0`|
+|`src`| string (uri, hashtag/filter) | `#cube`
`#sometag`
#cube&-ball_inside_cube`
`#-sky&-rain`
`#-language&english`
`#price=>5`
`https://linux.org/penguin.png`
`https://linux.world/distrowatch.gltf#t=1,100`
`linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply`
`androidapp://page1?tutorial#room1&t1,100`
`foo.mp3#0,0,0`|
Here's an ascii representation of a 3D scene-graph with 3D objects `◻` which embeds remote & local 3D objects `◻` with/out using filters:
@@ -569,7 +569,7 @@ navigation, portals & mutations
| fragment | type | example value |
|----------|---------------------------------|---------------------------------------------------------------------------------------------------------------------------|
-|`href` | string (uri or predefined view) | `#room1`
`#pos=room1&rot=90,0,0`
`://somefile.gltf#room1`
|
+|`href` | string (uri or predefined view) | `#room1`
`#room1&rot=90,0,0`
`://somefile.gltf#room1`
|
1. clicking an outbound ''external''- or ''file URI'' fully replaces the current scene and assumes `room2&rot=0,0,0` by default (unless specified)
@@ -1055,9 +1055,9 @@ This approach aligns with the idea that extensions are more likely to be interpr
2. **Fallback Fall-through Mechanism**:
If a glTF implementation does not support a particular extension, the (XRF) extras field can serve as a fallback. This way, metadata provided in extras can still be useful for applications that don't handle certain extensions.
-> **Example 1** In case of the OMI_LINK glTF extension (`href: https://nlnet.nl`) and an XR Fragment (`href: #pos=otherroom` or `href: otherplanet.glb`), it is clear that `https://nlnet.nl` should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (`#pos=` e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
+> **Example 1** In case of the OMI_LINK glTF extension (`href: https://nlnet.nl`) and an XR Fragment (`href: #otherroom` or `href: otherplanet.glb`), it is clear that `https://nlnet.nl` should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (`#room1` e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
-> **Example 2** If an Extensions uses XR Fragments in URI's (`href: #pos=otherroom` or `href: xrf://-walls` in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
+> **Example 2** If an Extensions uses XR Fragments in URI's (`href: #otherroom` or `href: xrf://-walls` in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
## Vendor Prefixes
diff --git a/doc/RFC_XR_Fragments.txt b/doc/RFC_XR_Fragments.txt
index 8356af8..504bfcc 100644
--- a/doc/RFC_XR_Fragments.txt
+++ b/doc/RFC_XR_Fragments.txt
@@ -1021,7 +1021,7 @@ Internet-Draft XR Fragments September 2025
| | |https://linux.world/distrowatch.gltf#t=1,100 |
| | |linuxapp://conference/nixworkshop/apply.gltf#- |
| | |cta&cta_apply |
- | | |androidapp://page1?tutorial#pos=0,0,1&t1,100 |
+ | | |androidapp://page1?tutorial#room1&t1,100 |
| | |foo.mp3#0,0,0 |
+--------+--------+---------------------------------------------------+
@@ -1142,7 +1142,7 @@ Internet-Draft XR Fragments September 2025
| fragment | type | example value |
+==========+==================+========================+
| href | string (uri or | #room1 |
- | | predefined view) | #pos=room1&rot=90,0,0 |
+ | | predefined view) | #room1&rot=90,0,0 |
| | | ://somefile.gltf#room1 |
+----------+------------------+------------------------+
@@ -2002,11 +2002,11 @@ Internet-Draft XR Fragments September 2025
extensions.
| *Example 1* In case of the OMI_LINK glTF extension (href:
- | https://nlnet.nl) and an XR Fragment (href: #pos=otherroom or
- | href: otherplanet.glb), it is clear that https://nlnet.nl should
- | open in a browsertab, whereas the XR Fragment links should
- | teleport the user. If the OMI_LINK contains an XR Fragment (#pos=
- | e.g.) a teleport should be performed only (and other [overlapping]
+ | https://nlnet.nl) and an XR Fragment (href: #otherroom or href:
+ | otherplanet.glb), it is clear that https://nlnet.nl should open in
+ | a browsertab, whereas the XR Fragment links should teleport the
+ | user. If the OMI_LINK contains an XR Fragment (#room1 e.g.) a
+ | teleport should be performed only (and other [overlapping]
| metadata should be ignored).
|
@@ -2019,9 +2019,9 @@ Internet-Draft XR Fragments September 2025
| *Example 2* If an Extensions uses XR Fragments in URI's (href:
- | #pos=otherroom or href: xrf://-walls in OMI_LINK e.g.), then
- | perform them according to XR Fragment spec (teleport user). But
- | only once: ignore further overlapping metadata for that usecase.
+ | #otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform
+ | them according to XR Fragment spec (teleport user). But only
+ | once: ignore further overlapping metadata for that usecase.
28.3. Vendor Prefixes
diff --git a/doc/RFC_XR_Fragments.xml b/doc/RFC_XR_Fragments.xml
index 293c234..5481391 100644
--- a/doc/RFC_XR_Fragments.xml
+++ b/doc/RFC_XR_Fragments.xml
@@ -706,7 +706,7 @@ It instances content (in objects) in the current scene/asset, and follows simila
#cube&-ball_inside_cube<br>#-sky&-rain<br>#-language&english<br>#price=>5<br>https://linux.org/penguin.png`
https://linux.world/distrowatch.gltf#t=1,100
linuxapp://conference/nixworkshop/apply.gltf#-cta&cta_apply
-androidapp://page1?tutorial#pos=0,0,1&t1,100
+androidapp://page1?tutorial#room1&t1,100
foo.mp3#0,0,0
@@ -788,7 +788,7 @@ Resizing will be happen accordingly to its placeholder object aquariumcubehref
string (uri or predefined view)
#room1
-#pos=room1&rot=90,0,0
+#room1&rot=90,0,0
://somefile.gltf#room1
@@ -1405,8 +1405,8 @@ This approach aligns with the idea that extensions are more likely to be interpr
Fallback Fall-through Mechanism:
If a glTF implementation does not support a particular extension, the (XRF) extras field can serve as a fallback. This way, metadata provided in extras can still be useful for applications that don't handle certain extensions.
-Example 1 In case of the OMI_LINK glTF extension (href: https://nlnet.nl) and an XR Fragment (href: #pos=otherroom or href: otherplanet.glb), it is clear that https://nlnet.nl should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (#pos= e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
-Example 2 If an Extensions uses XR Fragments in URI's (href: #pos=otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
+Example 1 In case of the OMI_LINK glTF extension (href: https://nlnet.nl) and an XR Fragment (href: #otherroom or href: otherplanet.glb), it is clear that https://nlnet.nl should open in a browsertab, whereas the XR Fragment links should teleport the user. If the OMI_LINK contains an XR Fragment (#room1 e.g.) a teleport should be performed only (and other [overlapping] metadata should be ignored).
+Example 2 If an Extensions uses XR Fragments in URI's (href: #otherroom or href: xrf://-walls in OMI_LINK e.g.), then perform them according to XR Fragment spec (teleport user). But only once: ignore further overlapping metadata for that usecase.
Vendor Prefixes