Re: [dxwg] property profileOfTransitive (#486)

At the bottom of this comment is a suggestion to improve wording to help people understand this matter.

But first it needs to be pointed out that there are at least three problems with the claims in the last comment  :

1) it is reverting to confusing the "logical" profile with a choice of representation - feel free to do the representation any way you like, but nothing about existing representations has bearing on the fact that logical profiles need to be separately identified and have relationships.
2) Nothing stops you choosing to flatten out your representations but that doesnt mean  you can or should impose that view on every community
3) Given that for example published OGC specifications in the form of profiles certainly do not repeat all the constraints of base specifications it would appear that you are not looking at a wide enough sample to attempt top draw any such conclusions.
4) "We did indeed conclude" does not reference any formal decision making process which is relevant here - and the cited issue #228 actually supports the opposite view - the suggestion in the title to the same effect there was also refuted. 

the actual conclusion in #228  was a consensus around some sort of statement like

"Profiles are hierarchical in nature but SHOULD be published as stand-alone resources containing all needed elements and constraints, as required by expected use."

noting that this 
a) does not make this mandatory and
b) specifically says "stand-alone resources" whist stating "Profiles are hierarchical in nature "

Its not well enough worded perhaps because we are not citing it naturally to remove this unnecessary sense of incompatibility with expectations.

Happy to improve the wording here - but this is fundamentally a user choice and thus is really a matter for guidance - not the profiles vocabulary, which merely provides a canonical mechanism to do this either or both ways. 

Can I suggest we make it more explicit:

"Although profiles may be hierarchical in nature it is considered advantageous to publish stand-alone resources containing all needed elements and constraints to fully describe a profile for convenience of systems so that the full hierarchy of profile descriptions and resources do not need to be accessed and merged during use.  Such stand-alone resources SHOULD indicated via import or annotation mechanisms which specifications require each constraint.  Profiles MUST use the "validation" role classifier to identify such resources if available."

I think that this addresses your underlying concern and requires no change (beyond improved annotations) to the 2PWD profiles vocabulary.






-- 
GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/486#issuecomment-524605551 using your GitHub account

Received on Sunday, 25 August 2019 06:39:50 UTC