Skip to content

Conversation

@relu91
Copy link
Member

@relu91 relu91 commented Jan 18, 2021

I tried to simplify the definition given during the last call. In particular, I dropped the term subset of because it could be understood as if a Partial TD could contain any element of the TD model without any particular order or structure (much like a TD fragment). I also remove the information about the serialization because I found it redundant.

@ashimura I linked the scripting API document in the Note. Did I use the correct link? Should I refer to the published document or the TR is ok? Sorry, I'm still confused a little bit about the publication process.


Preview | Diff

</dt>
<dd>
A <a>Partial TD</a> is an object that follows the same hierarchical structure of the <a>TD</a> information model,
but it may not contain all the mandatory elements.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposal looks good to me.

An alternative to
"but it may not contain all the mandatory elements. "
may be
"but it does not have to contain all mandatory elements."

I leave it to native speakers what is more clear....

@ashimura
Copy link
Contributor

ashimura commented Jan 19, 2021

@relu91 thanks for generating this PR!

Regarding the question of "which document to be cited for the reference", my suggestion is (always) using the dated "This version" URL of the published TR, i.e., https://www.w3.org/TR/2020/NOTE-wot-scripting-api-20201124/#the-produce-method, because the content of the undated "Latest published version URL (I.e., https://www.w3.org/TR/wot-scripting-api/#the-produce-method) tend to get changed.

BTW, regarding the term of "exposed thing", I think we should capitalize the words (="Exposed Thing") because the term is defined within the WoT Architecture spec :)

@relu91
Copy link
Member Author

relu91 commented Jan 19, 2021

@ashimura Thank you for your guidance. I've updated the PR accordingly.

@relu91
Copy link
Member Author

relu91 commented Jan 20, 2021

Another point, should we define the full name? In other words, should I rename the element to Partial Thing Description ?

@danielpeintner
Copy link
Contributor

Another point, should we define the full name? In other words, should I rename the element to Partial Thing Description ?

we used "partial TD" in the past and I think it is fine like it is without expanding it....
Anyhow, I don't have a strong opinion.

@danielpeintner
Copy link
Contributor

FYI: In today's scripting call we discussed the possibility of removing any mentioning of "partial TD" from the architecture terminology section.

Let me describe our thinking. As we see it, "partial TDs" are solely used in scripting (OR are there other documents referring to it?) and the scripting document could define it if needed. Having said that, in scripting we are thinking to use the term "ExposedThingInit" which seems more aligned with the web platform terminology...

We (@relu91, @danielpeintner, @zolkis, ...) are happy to also discuss it further in the architecture call.

@zolkis
Copy link
Contributor

zolkis commented Jan 25, 2021

For a larger context, the TD TF defines the outcome (Thing Description) for an exposed Thing, and does not specify how to make it (based on what input).

So Scripting needs to define how does it handle input for creating exposed Things. Currently it is a dictionary object that undergoes the input validation algorithm, that maps to this "partial TD" term.

Since Scripting is optional and is just a client, we (TD TF, Arch TF) still might need a broader definition on how to remotely create an exposed Thing, what input is accepted and how. Therefore the Arch TF could consider if this term is needed, despite being used only in Scripting (and actually not even there, as we separated the terminology/TD/partial TD validation problem from the JavaScript input type/validation problem).

@mlagally
Copy link
Contributor

I think we should preserve the definition in the terminology section of the architecture spec.
This may come at hand in other areas, e.g. discovery, thing directories, TD, ...

@mlagally mlagally merged commit 51d8f2a into w3c:master Jan 28, 2021
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

Successfully merging this pull request may close these issues.

5 participants