How can I reference the data in a node.js project and react based project

[jetro4u]

I will like to find out how I can reference the data in a node.js project and react based project. Also how to use the workflow in a project

[kevinduffey]

I am not sure if I understand what you are asking. I'll give it a shot though. I assume you are referring to the execution of a given workflow as if it were code, such that whatever is returned in the end step, say for example a workflow that buys a pet from a pet store, the result might be a payload (response body) that provides details about the transaction?

[handrews]

@jetro4u

I need clarification on this statement "In a multi-document description, the document containing the Arazzo Specification Object is known as the entry Arazzo document."

In the document description, the Arazzo specification object include REQUIRED field. So one can conclude that it should be included in all Arazzo documents. So how will the system differentiate what the entry document is if I define the specification in all of them. Or can I define a file without the specification and reference it from an Arazzo file?

@kevinduffey @frankkilcommins we tweaked the analogous language in OAS 3.0.4 and OAS 3.1.1 for this reason. We also did some clarifications of the YAML-related text. See:

• Clarify entry/complete document terminology (3.0.4) OpenAPI-Specification#3820
• Various minor editorial improvements (3.0.4) OpenAPI-Specification#3861

You might want to adopt something similar in Arazzo 1.0.1.

[kevinduffey]

@jetro4u the entry document would be the one that has the imports of other documents. So whatever tool is used to parse/do something would use the Arazzo object (at the top) of the first document loaded.. imported workflow docs would be more akin to inlined workflows where the Arazzo object would likely be ignored (other than perhaps to match version info and/or details of imported docs). In the entry document, you would not utilize the header of imported docs, you would be referencing workflows, steps and components within those docs.

As @handrews eluded to, and shared links, the Complete Document wording would indicate everything is contained in the one document which I would assume means no imports of other Arazzo documents. Though in the case of Arazzo you likely have OpenAPI documents you import so not entirely sure if "Complete Document" definition would still fit this as it does OpenAPI.

[jetro4u]

I'm building an Isomorphic Adapter that also parse the yaml and json document. I guess I'll need to design my project such that only the entry document reference other documents. Given the short time I have it'll be easier to also wrap up the library and expand the functionality later.

[handrews]

@kevinduffey actually "complete document" does not mean it's self-contained, just that it's not a fragment (naming is hard!) A fragment would be something like a document containing only a Path Item Object. This sort of thing was typical in 2.0 and is still quite common in 3.0. It causes a lot of problems in OAS 3.1, which is explained much more clearly in the forthcoming 3.1.1. Although 3.1 makes it more beneficial to have standalone JSON Schema documents, which technically are fragments in OAS terms. Hopefully 3.1.1 makes more sense in this area as it has been a challenge for a lot of tooling vendors.

So the thing here is that you can have multiple complete documents (at least in OAS) that are connected with references, in which case you have to designate one of them as the entry document somehow (even if it's just "whatever is passed to the tool first is the entry document"). On the other hand, if you only have one complete document and all other documents are fragments, then you can safely assume the complete document is the entry document. I think that's the scenario everyone had in mind with the original entry document wording (even though that scenario is problematic in OAS 3.1).

[jetro4u]

Just curios, is there existing interface that define the Arazzo specs like the OpenAPIV3_1