OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCORE-13) dialogs-v3.html final editing issues


    [ https://issues.oasis-open.org/browse/OSLCCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59680#comment-59680 ] 

James Amsden commented on OSLCCORE-13:
--------------------------------------

Actually clarification from Chet indicates that an OASIS specification can have normative references to any document it wants subject to TC approval. He provided a list of questions that should all be answered yes in order to be a normative reference:
- Do we actually reference it in our specification? (You would be surprised how often we've sent feedback to a TC asking 'hey, you cite this in your references but we can't find a reference anywhere in the spec...') 

- Do we need to reference it? Is it true that you can't implement our spec without using the referenced work explicitly or implicitly? 

- Can we rely on it? Is it stable? Are updates and changes handled in a predictable and transparent way? Do updates and changes happen through a governed process or is it possible that this thing could changes on us without warning and with no assurances of backwards compatibility? 

- Does it live someplace where we can reliably reference it? If we cite to it, can we be certain that it will still be there this time next year? 

- Can our adopters get access to it either free or for a reasonable cost? If accessing it costs money, is there an alternative we can use that does not? 

Chet's recommendation: If you can answer 'yes' to all of these, then you can confidently cite it as a normative reference. If you can't, then you may want to do some further thinking. 

This means that OSLC Core 3.0 can continue to reference the existing open-services.net ResourceShapes specification in a normative way.


> dialogs-v3.html final editing issues
> ------------------------------------
>
>                 Key: OSLCCORE-13
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-13
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> 1. Section 5.3 Prefill, should oslc:resourceShape be ldp:constrainedBy to provide flexibility for how the dialog contents would be constrained? This would decouple dialogs from OSLC 2.0 Resource Shapes.
> Dialog property oslc:resourceShape is not sufficiently defined. It specifies the constraints for the dialog, but does not say how these constraints are specified in a standard way.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]