-
Notifications
You must be signed in to change notification settings - Fork 44
Introduce Partial TD definition #577
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
Conversation
| </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. |
There was a problem hiding this comment.
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....
|
@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 :) |
|
@ashimura Thank you for your guidance. I've updated the PR accordingly. |
|
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.... |
|
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. |
|
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). |
|
I think we should preserve the definition in the terminology section of the architecture spec. |
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