diff --git a/doc/RFC_XR_Fragments.html b/doc/RFC_XR_Fragments.html index 9a3d6cc..dc99f68 100644 --- a/doc/RFC_XR_Fragments.html +++ b/doc/RFC_XR_Fragments.html @@ -86,6 +86,9 @@ XR Fragments allows us to better use existing metadata inside 3D scene(files), b XR Fragments views spatial webs thru the lens of 3D scene URI’s, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.).

+

XR Fragments is a Meta scene format which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.
+These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing higher interop between fileformats, 3D editors, viewers and game-engines.

+

Almost every idea in this document is demonstrated at https://xrfragment.org

@@ -1517,13 +1520,13 @@ For example, GLTF has the OMI_LINK extension which might overlap wi

Priority Order and Precedence, otherwise fallback applies

-

1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s +

1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s specific needs and optimizations in mind, they should take precedence over extras metadata in cases where both contain overlapping functionality. This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software.

-
    -
  1. Fallback Fall-through Mechanism: +
      +
    1. 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.
    diff --git a/doc/RFC_XR_Fragments.md b/doc/RFC_XR_Fragments.md index 55cc332..3d8d53e 100644 --- a/doc/RFC_XR_Fragments.md +++ b/doc/RFC_XR_Fragments.md @@ -98,6 +98,9 @@ The specification uses [W3C Media Fragments](https://www.w3.org/TR/media-frags/) XR Fragments allows us to better use existing metadata inside 3D scene(files), by connecting it to proven technologies like [URI Fragments](https://en.wikipedia.org/wiki/URI_fragment).
    XR Fragments views spatial webs thru the lens of 3D scene URI's, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.). +> XR Fragments is a Meta scene format which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.
    +These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing higher interop between fileformats, 3D editors, viewers and game-engines. + > Almost every idea in this document is demonstrated at [https://xrfragment.org](https://xrfragment.org) {mainmatter} @@ -963,12 +966,12 @@ For example, GLTF has the `OMI_LINK` extension which might overlap with XR Fragm > Priority Order and Precedence, otherwise fallback applies -1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s +1.**Extensions Take Precedence**: Since glTF-specific extensions are designed with the format’s specific needs and optimizations in mind, they should take precedence over extras metadata in cases where both contain overlapping functionality. This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software. -3. Fallback Fall-through Mechanism: +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). diff --git a/doc/RFC_XR_Fragments.txt b/doc/RFC_XR_Fragments.txt index e014566..8273940 100644 --- a/doc/RFC_XR_Fragments.txt +++ b/doc/RFC_XR_Fragments.txt @@ -28,6 +28,14 @@ Abstract rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.). + XR Fragments is a Meta scene format which leverages heuristic + rules derived from any 3D scene or well-established 3D file formats, + to extract meaningful features from scene hierarchies. + These heuristics, enable features that are both meaningful and + consistent across different scene representations, allowing higher + interop between fileformats, 3D editors, viewers and game- + engines. + Almost every idea in this document is demonstrated at https://xrfragment.org (https://xrfragment.org) @@ -41,14 +49,6 @@ Status of This Memo working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 29 March 2025. - - @@ -58,6 +58,13 @@ van Kammen Expires 29 March 2025 [Page 1] Internet-Draft XR Fragments September 2024 + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 29 March 2025. + Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the @@ -99,13 +106,6 @@ Table of Contents 15.1. including/excluding . . . . . . . . . . . . . . . . . . 23 15.2. Filter Parser . . . . . . . . . . . . . . . . . . . . . 24 16. Visible links . . . . . . . . . . . . . . . . . . . . . . . . 25 - 17. Text in XR (tagging,linking to spatial objects) . . . . . . . 25 - 17.1. Default Data URI mimetype . . . . . . . . . . . . . . . 28 - 17.2. URL and Data URI . . . . . . . . . . . . . . . . . . . . 29 - 18. Importing/exporting . . . . . . . . . . . . . . . . . . . . . 30 - 19. Reflection Mapping . . . . . . . . . . . . . . . . . . . . . 30 - 20. Transclusion (broken link) resolution . . . . . . . . . . . . 30 - 21. Topic-based index-less Webrings . . . . . . . . . . . . . . . 31 @@ -114,6 +114,13 @@ van Kammen Expires 29 March 2025 [Page 2] Internet-Draft XR Fragments September 2024 + 17. Text in XR (tagging,linking to spatial objects) . . . . . . . 25 + 17.1. Default Data URI mimetype . . . . . . . . . . . . . . . 28 + 17.2. URL and Data URI . . . . . . . . . . . . . . . . . . . . 29 + 18. Importing/exporting . . . . . . . . . . . . . . . . . . . . . 30 + 19. Reflection Mapping . . . . . . . . . . . . . . . . . . . . . 30 + 20. Transclusion (broken link) resolution . . . . . . . . . . . . 30 + 21. Topic-based index-less Webrings . . . . . . . . . . . . . . . 31 22. URI Templates (RFC6570) . . . . . . . . . . . . . . . . . . . 32 23. Additional scene metadata . . . . . . . . . . . . . . . . . . 32 24. Accessibility interface . . . . . . . . . . . . . . . . . . . 33 @@ -156,13 +163,6 @@ Internet-Draft XR Fragments September 2024 5. the gap between text an 3d objects: object-names directly map to hashtags (=fragments), which allows 3D to text transcription. - | NOTE: The chapters in this document are ordered from highlevel to - | lowlevel (technical) as much as possible - - - - - van Kammen Expires 29 March 2025 [Page 3] @@ -170,6 +170,9 @@ van Kammen Expires 29 March 2025 [Page 3] Internet-Draft XR Fragments September 2024 + | NOTE: The chapters in this document are ordered from highlevel to + | lowlevel (technical) as much as possible + 2. Core principle *XR Fragments allows controlling 3D models using URLs, based on @@ -218,9 +221,6 @@ Internet-Draft XR Fragments September 2024 - - - van Kammen Expires 29 March 2025 [Page 4] Internet-Draft XR Fragments September 2024 @@ -1914,14 +1914,14 @@ Internet-Draft XR Fragments September 2024 | Priority Order and Precedence, otherwise fallback applies - 1.Extensions Take Precedence: Since glTF-specific extensions are + 1.*Extensions Take Precedence*: Since glTF-specific extensions are designed with the format’s specific needs and optimizations in mind, they should take precedence over extras metadata in cases where both contain overlapping functionality. This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software. - 3. Fallback Fall-through Mechanism: If a glTF implementation does + 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 diff --git a/doc/RFC_XR_Fragments.xml b/doc/RFC_XR_Fragments.xml index c74d898..280190e 100644 --- a/doc/RFC_XR_Fragments.xml +++ b/doc/RFC_XR_Fragments.xml @@ -17,6 +17,9 @@ The specification uses W3C Med XR Fragments allows us to better use existing metadata inside 3D scene(files), by connecting it to proven technologies like URI Fragments.
    XR Fragments views spatial webs thru the lens of 3D scene URI's, rather than thru code(frameworks) or protocol-specific browsers (webbrowser e.g.). +XR Fragments is a <b>Meta scene format</b> which leverages heuristic rules derived from any 3D scene or well-established 3D file formats, to extract meaningful features from scene hierarchies.
    + +These heuristics, enable features that are both meaningful and consistent across different scene representations, allowing <b>higher interop</b> between fileformats, 3D editors, viewers and game-engines.     Almost every idea in this document is demonstrated at https://xrfragment.org @@ -1351,13 +1354,13 @@ Therefore a 2-button navigation-interface is the bare minimum interface: What if the functionality of those overlap? For example, GLTF has the OMI_LINK extension which might overlap with XR Fragment's href:
    Priority Order and Precedence, otherwise fallback applies -
    1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s +1.Extensions Take Precedence: Since glTF-specific extensions are designed with the format’s specific needs and optimizations in mind, they should take precedence over extras metadata in cases where both contain overlapping functionality. This approach aligns with the idea that extensions are more likely to be interpreted uniformly by glTF-compatible software. -
      -
    1. Fallback Fall-through Mechanism: +
        +
      1. 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). diff --git a/index.html b/index.html index 43b32cf..419d891 100644 --- a/index.html +++ b/index.html @@ -520,8 +520,6 @@ button.sidebar-toggle{
    2. 🖥 Blender ✅🔥
      3. -
    3. 🧩 Object metadata
      4. -
    4. 🧰 <model-viewer>
    5. 🧰 AFRAME
      6. @@ -732,6 +730,8 @@ button.sidebar-toggle{
    6. $:/state/toc/Reference/📜 XR Fragments-🧩 Object metadata--403145756
      7. +
    7. $:/state/toc/Reference/📜 XR Fragments-extras--403145756
      8. +
    8. $:/state/toc/Reference/🧰 libraries-XR Fragment parser--403145756
    9. $:/state/toc/Reference/js/AFRAME-THREE.js--403145756
      10. @@ -846,6 +846,8 @@ button.sidebar-toggle{
    10. interlinked.png
      11. +
    11. metadata extras
      12. +
    12. mov
    13. multiparty networking
      14. @@ -974,7 +976,7 @@ button.sidebar-toggle{