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.

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

Add Ability to Retrieve Original TD #165

Open
mmccool opened this issue Apr 26, 2021 · 5 comments
Open

Add Ability to Retrieve Original TD #165

mmccool opened this issue Apr 26, 2021 · 5 comments

Comments

@mmccool
Copy link
Contributor

mmccool commented Apr 26, 2021

Current spec makes "enriched" TDs the default. In various contexts we need access to the original, unmodified TDs. There may also be cases where a directory chooses to omit some data based on access rights. For this it might be useful to have "categories" of enriched metadata.

  • Still don't have the "enriched" query parameter; proposal is to add "original" query filter option
  • This would return the EXACT string provided during registration
  • Should this only be supported if the input was canonicalized, otherwise it returns an "unenriched" form with all the same data as the input, but order of elements, white space, etc. might be different? More complex, but allows implementation via round-tripping as opposed to storing the exact input string. To discuss.

Originally posted by @mmccool in #163 (comment)

@relu91
Copy link
Member

relu91 commented Jul 5, 2022

The current spec does not require to return of an enriched TD by default (Am I missing something?). This makes impossible to "manage" an anonymous TD if you lost the content of the Location Header. It would be nice to bring back the discussion about this:

Still don't have the "enriched" query parameter; proposal is to add "original" query filter option

IMHO we need to have the ability to ask for the enriched form when retrieving on listing TDs.

@farshidtz
Copy link
Member

farshidtz commented Jul 5, 2022

We have forgotten to add the query argument. However Anonymous TDs must have the id embedded in them.

Maybe id isn't part of enriched TD. I can't find the definition of an Enriched TD.

In situations where the server exposes an Anonymous TD (e.g. retrieval, listing, search), it MUST add the local identifier to the TD to allow local referencing.
https://w3c.github.io/wot-discovery/#exploration-directory-anonymous-td

@relu91
Copy link
Member

relu91 commented Jul 6, 2022

Oh, that's right somehow I didn't find the assertion even if I recalled something like that.... 🤔 . I was looking here: https://w3c.github.io/wot-discovery/#exploration-directory-api-things-creation and here https://w3c.github.io/wot-discovery/#exploration-directory-api-things-retrieval. They feel like a better place for that assertion, but I would leave the final decision to the editors.

Maybe id isn't part of enriched TD. I can't find the definition of an Enriched TD.

In my understanding, after we moved the definition to architecture we lost the UML diagram with additional details about the Enriched TD. However, given the definition from arch:

A Thing Description embedded with additional attributes for bookkeeping and discovery.

I would say that is possible to think of the id as additional attributes added for bookkeeping.

@mmccool
Copy link
Contributor Author

mmccool commented Aug 22, 2022

May be related to issue #257. Modifications to TDs are needed for several use cases, such as proxies, but are also troublesome from a security point of view. A resolution would be to always allow verbatim retrieval of the original TD, which may be needed anyway for signatures. However, in a practical sense I don't think we have TIME to fix this, so will mark as both "Resolve by CR", "Discuss", and "Defer to Discovery 2.0". One "resolution" would be to defer to Discovery 2.0.

@mmccool mmccool added Discuss Resolve by CR Issues that need to be resolved by CR defer to Discovery 2.0 labels Aug 22, 2022
@mmccool
Copy link
Contributor Author

mmccool commented Sep 5, 2022

Resolution (Discovery call 2022.9.5): Defer to 2.0.

@mmccool mmccool removed Discuss Resolve by CR Issues that need to be resolved by CR labels Sep 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants