Re: [dxwg] Query string implementation of profile selection (#544)

@agreiner:

> I still don't see anything reassuring to developers that explains whether they can just build something that conforms to the abstract model without also formalizing and posting a "profile" for it.

What environment are your developers likely to build for? If it's the "HTTP environment", then the HTTP Functional Profile may be all they need. If it's GraphQL, and that's seen by you/them as a separate environment, then they'll have to implement a new Functional Profile that defines how the Abstract Specification is implemented in that environment.

I expect that new environment implementers may often implement both HTTP and some other new Functional Profile. This is what I've done with pyLDAPI and the demo implementation at http://conneg.info/mediatypes but for CKAN work, I can't emit all the required HTTP headers since the system's behind layers of proxies that knock them out so I can't make it conformant with the HTTP spec and thus it's only going to be conformant with QSA Alternate Keywords FP.

I do expect to make a GraphQL Environment FP as I'm interested in GraphQL unles someone makes one first, and again, implementations conforming to that spec are likely to conform to HTTP if the implementing system can also emit HTTP headers (I guess depends the particular implementation).

So, what's the environment you're most likely to implement in? If HTTP, QSA or QSA Alt Keywords, there's already an FP for you (which you might disagree with and make another) but if another environment, what is it?

-- 
GitHub Notification of comment by nicholascar
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/544#issuecomment-545715992 using your GitHub account

Received on Thursday, 24 October 2019 02:37:48 UTC