W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > July 2019

Re: [dxwg] Revisiting the definition of "profile" (#963)

From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Jul 2019 00:12:50 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-509856042-1562717569-sysbot+gh@w3.org>
It feels like we are at last getting to grips with this beast :-).  

It seems the concept of specification is made more complex by the sense its something to conform to, and the use of it for documents that do more than specify things, or may contain multiple such specifications.
Simon was on the money when he explicitly modelled "conformanceClass" as the specifying component of a specification document - but thats not really a "mass market" accessible set of terminology.

In my mind I'm happy to think of the specification component of a specification document as a "profile" - so a specification document may have a mandatory profile and a recommended profile - or multiple discrete cases of each of these. 

I think we cant fix use of "specification" as a noun (i.e. define it well enough) because of its conflicting but common usage senses - but as a verb it does describe a role well enough.  

More than happy to try to explicitly model the idea of a specification document containing multiple profiles - the OGC example shows how a naming policy can be enforced - but that's a corner case against legacy documents.

I think we have a choice:
1) define a convention and mechanism for describing how "specification document" objects can be polymorphic (act as a mandatory profile and a recommendation profile and a guidance note and a set of examples etc)   - nb I think this can already be handled in Profiles ontology using roles, but we may want to define role like "mandatoryCore" - so a profile can state it represents that part of a document.
2) limit scope to cases where the equivalent of "conformanceClass" is explicitly named - we just use those names as references - profiles or X ('specification' seems not to work)
3) specify a mechanism to provide names for the different components within a specification document and define how each named thing is related to the original document. 
4) some other idea ?

Once we have consensus about the relationship of profile to "specification" I can model options to describe - but I feel that my original "computer scienc-y" view that each "conformanceClass" is naturally a profile of itself can be extended happily to "each specification document describes a number of possible profiles of the specification" - and we just need a single notion of profiles - as per conneg-by-ap (and consistent with @tombaker comments on this matter)

GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/963#issuecomment-509856042 using your GitHub account
Received on Wednesday, 10 July 2019 00:12:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:18 UTC