|
[OSLC forum] [oslc4j-client] Can't specify Configuration Context in parameters and/or headers
Jim, Nick, I might need your advice before making changes to the client.
toggle quoted messageShow quoted text
--
/Andrew
(from phone)
Vidarebefordrat brev:
|
||
|
|
||
|
Re: SC errors
Thanks a lot, Nick! The PRs now build successfully.
-- –Andrew.
Från:
Nicholas Crossley <nick_crossley@...>
Fixed this by updating ShapeChecker to the latest Jena and latest Apache HttpClient.
I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:
curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core-v * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 80 (#0) > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 301 Moved Permanently < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/html < Content-Length: 194 < Connection: keep-alive < Location: https://open-services.net/ns/core < * Ignoring the response-body * Connection #0 to host open-services.net left intact * Issue another request to this URL: 'https://open-services.net/ns/core' * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 443 (#1) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=open-services.net * start date: Jun 25 16:46:12 2019 GMT * expire date: Sep 23 16:46:12 2019 GMT * subjectAltName: host "open-services.net" matched cert's "open-services.net" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 200 OK < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/turtle; charset=UTF-8 < Content-Length: 25162 < Connection: keep-alive < X-Powered-By: Express < Accept-Ranges: bytes < Cache-Control: public, max-age=0 < Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT < ETag: W/"624a-160c4b70260" < @prefix dcterms: <http://purl.org/dc/terms/>. @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix dcterms: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix vann: <http://purl.org/vocab/vann/> . @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>. @prefix oslc: <http://open-services.net/ns/core#> .
oslc: a owl:Ontology ; dcterms:title "The OSLC Core Vocabulary" ; dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ; dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ; vann:preferredNamespacePrefix "oslc" ; rdfs:label "Core" .
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Nick,
As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:
openssl s_client -connect archive.open-services.net:443 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = archive.open-services.net verify return:1 --- Certificate chain 0 s:/CN=archive.open-services.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Thanks Nick, great work! We will fix the TLS certs. -- /Andrew (from phone)
Andrew,
Nick,
Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#
-- –Andrew.
|
||
|
|
||
|
Re: SC errors
Nick Crossley <nick_crossley@...>
Fixed this by updating
ShapeChecker to the latest Jena and latest Apache HttpClient.
Nick. From: Andrii Berezovskyi <andriib@...> To: "oslc-op@..." <oslc-op@...>, Nicholas Crossley <nick_crossley@...> Cc: "fabio.ribeiro@..." <fabio.ribeiro@...> Date: 07/29/2019 08:41 AM Subject: [EXTERNAL] Re: [oslc-op] SC errors I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:
curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core-v * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 80 (#0) > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 301 Moved Permanently < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/html < Content-Length: 194 < Connection: keep-alive < Location: https://open-services.net/ns/core < * Ignoring the response-body * Connection #0 to host open-services.net left intact * Issue another request to this URL: 'https://open-services.net/ns/core' * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 443 (#1) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=open-services.net * start date: Jun 25 16:46:12 2019 GMT * expire date: Sep 23 16:46:12 2019 GMT * subjectAltName: host "open-services.net" matched cert's "open-services.net" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 200 OK < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/turtle; charset=UTF-8 < Content-Length: 25162 < Connection: keep-alive < X-Powered-By: Express < Accept-Ranges: bytes < Cache-Control: public, max-age=0 < Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT < ETag: W/"624a-160c4b70260" < @prefix dcterms: <http://purl.org/dc/terms/>. @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix dcterms: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix vann: <http://purl.org/vocab/vann/> . @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>. @prefix oslc: <http://open-services.net/ns/core#> .
oslc: a owl:Ontology ; dcterms:title "The OSLC Core Vocabulary" ; dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ; dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ; vann:preferredNamespacePrefix "oslc" ; rdfs:label "Core" .
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii
Berezovskyi <andriib@...>
Nick,
As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:
openssl s_client -connect archive.open-services.net:443 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = archive.open-services.net verify return:1 --- Certificate chain 0 s:/CN=archive.open-services.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii
Berezovskyi <andriib@...>
Thanks Nick, great work! We will fix the TLS certs. -- /Andrew (from phone)
Andrew,
Nick,
Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#
-- –Andrew.
|
||
|
|
||
|
Re: SC errors
I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:
curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core -v * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 80 (#0) > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 301 Moved Permanently < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/html < Content-Length: 194 < Connection: keep-alive < Location: https://open-services.net/ns/core < * Ignoring the response-body * Connection #0 to host open-services.net left intact * Issue another request to this URL: 'https://open-services.net/ns/core' * Trying 165.227.5.255... * TCP_NODELAY set * Connected to open-services.net (165.227.5.255) port 443 (#1) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=open-services.net * start date: Jun 25 16:46:12 2019 GMT * expire date: Sep 23 16:46:12 2019 GMT * subjectAltName: host "open-services.net" matched cert's "open-services.net" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. > GET /ns/core HTTP/1.1 > Host: open-services.net > User-Agent: curl/7.54.0 > Accept: text/turtle,application/rdf+xml > < HTTP/1.1 200 OK < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 15:38:41 GMT < Content-Type: text/turtle; charset=UTF-8 < Content-Length: 25162 < Connection: keep-alive < X-Powered-By: Express < Accept-Ranges: bytes < Cache-Control: public, max-age=0 < Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT < ETag: W/"624a-160c4b70260" < @prefix dcterms: <http://purl.org/dc/terms/>. @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix dcterms: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix vann: <http://purl.org/vocab/vann/> . @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>. @prefix oslc: <http://open-services.net/ns/core#> .
oslc: a owl:Ontology ; dcterms:title "The OSLC Core Vocabulary" ; dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ; dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ; vann:preferredNamespacePrefix "oslc" ; rdfs:label "Core" .
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Nick,
As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:
openssl s_client -connect archive.open-services.net:443 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = archive.open-services.net verify return:1 --- Certificate chain 0 s:/CN=archive.open-services.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Thanks Nick, great work! We will fix the TLS certs. -- /Andrew (from phone)
|
||
|
|
||
|
Re: SC errors
Nick,
As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:
openssl s_client -connect archive.open-services.net:443 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = archive.open-services.net verify return:1 --- Certificate chain 0 s:/CN=archive.open-services.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Thanks Nick, great work! We will fix the TLS certs. -- /Andrew (from phone)
|
||
|
|
||
|
Re: [tosca] 2019 Open Standards Cup winners
Paul Lipton <paul.lipton@...>
Hello Chet,
On behalf of the TOSCA TC, our thanks for being considered. We are very pleased to find ourselves in great company as a category finalist. That said; please be aware that TOSCA will be coming on strong in 2020, and that as a past Open Standards Cup winner, we aspire to be in the winner’s circle again next year!
Best regards, Paul
From: tosca@... <tosca@...>
On Behalf Of Chet Ensign
All,
I am pleased to announce the winners of the 2019 Open Standards Cup. We had a number of deserving projects and standards this year and all are truly deserving of recognition and applause.
2019 Outstanding Approved Winner
My thanks to the members of the TAB for their consideration and time to select the finalists.
Our congratulations on all the candidates.
Chet Ensign Chief Technical Community Steward
|
||
|
|
||
|
Re: SC errors
Thanks Nick, great work! We will fix the TLS certs.
toggle quoted messageShow quoted text
--
/Andrew
(from phone)
|
||
|
|
||
|
Re: SC errors
Nick Crossley <nick_crossley@...>
Andrew,
I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker. However, we still get some hard errors - one is due to the pain-in-the-neck redirect from open-services.net wiki to archive.open-services.net and the name mismatch for the SSL certificate: Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors) While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error: Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>) Can you fix that in the http/https setup somewhere? I still do not believe there is any benefit in that entire 'archive.open-services.net' thing! Nick. From: Andrii Berezovskyi <andriib@...> To: Nick Crossley <nick_crossley@...> Cc: "oslc-op@..." <oslc-op@...> Date: 07/25/2019 09:28 AM Subject: [EXTERNAL] SC errors Nick,
Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#
-- –Andrew.
|
||
|
|
||
|
Problems with OASIS Latest version URLs
Chet,
There are two problems with the OASIS Latest version URL for Open Project documents. Here's an example from the OSLC Change Management 3.0 specification: Latest version: http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.html(Authoritative) http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.pdf First, its not the latest version of a specification, its the latest revision of a version. Once a document becomes an OASIS standard, then it can no longer have revisions. Any changes have to be done in a new version. Since the OASIS Latest version URL contains the version identifier in the URL, it cannot link to the latest version, only the latest revision. The second problem is that the docs.oasis-open.net host is changing to docs.oasis-open-project.net. We assume the reason for this is that OASIS doesn’t want to have different naming conventions in the same document library, and they are not keen to change the naming conventions to address the issues we’ve raised over relative links and file names. But as a result, the OASIS Latest version URI is not stable - as the OSLC specs move from a TC to an OP, the latest version URL changes. This raises the question of what the old TC latest version should point to. Or a question on the relationship between closed TC documents that have migrated to OP. The goal is to ensure that the latest version URL in any version of an OSLC OASIS published document (TC or OP) always links to what it says - the latest version, that URL and any required redirects are properly maintained, and the URL is stable, or if it changes, the old URLs are still properly updated. Our recommendation is to remove the version identifier from the latest version URL going forward, and manage the transition with redirects at docs.oasis-open.net. Alternatively we may introduce multiple latest version URLs, one managed by OASIS and another managed by the oslc-op using open-services.net to host the URL and manage the redirects. We need to resolve this issue in order to know what URL to use for the Latest version in PSD documents we are trying to get published. -- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575
|
||
|
|
||
|
SC errors
Nick,
Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#
-- –Andrew.
|
||
|
|
||
|
Re: oslc-op meeting minutes 2019-07-25
Could you please publish them on oslc-admin as previous minutes? HackMD is just a temp editing place.
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Jim Amsden <jamsden@...>
See
https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view
|
||
|
|
||
|
oslc-op meeting minutes 2019-07-25
See https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view
-- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575
|
||
|
|
||
|
Re: Please review the agenda for tomorrow's oslc-op meeting
I can join a short call next week.
-- –Andrew.
Från:
<oslc-op@...> på uppdrag av Chet Ensign <chet.ensign@...>
Hey Jim, Paul and I are in staff and board meetings this week but on the issue of finalizing the template/style sheets, how about we get on a call together next week and walk through all the remaining questions/issues and close on them together? Will you all have time free?
/chet
On Wed, Jul 24, 2019 at 11:01 AM Jim Amsden <jamsden@...> wrote:
--
Chet Ensign Chief Technical Community Steward
|
||
|
|
||
|
Re: Please review the agenda for tomorrow's oslc-op meeting
Nick,
All good points. Comments embedded below, and I've removed the ones that have no comments for clarity... -- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575 From: "Nick Crossley" <nick_crossley@...> To: oslc-op@... Date: 07/24/2019 12:41 PM Subject: [EXTERNAL] Re: [oslc-op] Please review the agenda for tomorrow's oslc-op meeting Sent by: oslc-op@... Some comments on the numbered issues in the agenda, for discussion tomorrow: 3. Format for published document URLs See above for URLs. Good that we can use relative links. For ReSpec, once we have agreement I can change ReSpec to be compliant. I could also keep the label field but have it generated by default from the other four fields (shortName, oslcVersion, specStatus and revision); this might be useful for non-standards track documents or notes. <jra>I would recommend removing the label field, ReSpec properties are confusing enough. I think non-standards track document (e.g, Project Note) follow similar naming conventions.</jra> 4. URL to the immutable, authoritative revision of PSD, PS, COS and OS specifications I find the suggested URL (https://github.com/oslc-op/oslc-specs/blob/cm-v3.0-psd01/specs/cm/change-mgt-spec.html) unacceptable. That *is* a rendered version, contrary to the statement that the the authoritative version be the actual source and not a rendered version: it is rendered to show all sorts of extra github info which is not part of the spec. Far better is https://raw.githubusercontent.com/oslc-op/oslc-specs/cm-v3.0-psd01/specs/cm/change-mgt-spec.html. In this particular case, the fact that this is delivered without content negotiation is a plus - you get the raw source rather than an HTML rendering. <jra>Agreed the far better URI is indeed far better. Lets use that</jra> 5. Where permanent links will be established to specifications. "Once an open-services.net redirect opens an actual specification, the reader will see the appropriate this, previous and latest OASIS links." The 'latest version' link is the one that concerns me the most - what if the latest is no longer at OASIS, or at least not where OASIS thought it was at that time? Can OASIS guarantee to have a stable URL for 'latest' that always follows the spec wherever it goes in the future? There's already the potential issue about versions of the spec, as opposed to revisions - what will the OASIS 'latest' link for Core 3.0 PSD 01 point to after Core 4.0 is published? <jra>re: "what if the latest is no longer at OASIS" - then all bets are off because the specs are no longer under OASIS governance and perhaps the OASIS document library is no longer accessible. But I don't think this is an issue. OASIS guarantees the preservation of these published documents and their URLs, that's what membership dues are for and why OASIS has naming conventions. So I have no problem having an open-services.net redirect to a docs.oasis-open-project resource.<jra> 6. Additional components URLs also need to be generated Given the agreement in (3) that relative links are OK, I think we should use those. <jra>OASIS may insist on the full URL. Or we can try again to make these proper HTML anchors, and not display the URL at all. That would be my much preferred solution. Note however if anyone copied any of these links, they might not work if only the relative link is copied.</jra> Nick. From: "Jim Amsden" <jamsden@...> To: oslc-op@... Date: 07/24/2019 08:02 AM Subject: [EXTERNAL] [oslc-op] Please review the agenda for tomorrow's oslc-op meeting Sent by: oslc-op@... Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view -- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575
|
||
|
|
||
|
Re: Please review the agenda for tomorrow's oslc-op meeting
Nick Crossley <nick_crossley@...>
Some comments on
the numbered issues in the agenda, for discussion tomorrow:
1. OP Project Specification format and OASIS boilerplate OK. 2. Where OP specifications are published Where OASIS publishes specs is indeed up to OASIS. However, I would still prefer we separate that from the URLs that we recommend and display to users, provided the URLs we do recommend and display resolve to the same place. In other words, no one has yet convinced me we are not better off using open-services.net and redirects - see my response to point 5. 3. Format for published document URLs See above for URLs. Good that we can use relative links. For ReSpec, once we have agreement I can change ReSpec to be compliant. I could also keep the label field but have it generated by default from the other four fields (shortName, oslcVersion, specStatus and revision); this might be useful for non-standards track documents or notes. 4. URL to the immutable, authoritative revision of PSD, PS, COS and OS specifications I find the suggested URL (https://github.com/oslc-op/oslc-specs/blob/cm-v3.0-psd01/specs/cm/change-mgt-spec.html) unacceptable. That *is* a rendered version, contrary to the statement that the the authoritative version be the actual source and not a rendered version: it is rendered to show all sorts of extra github info which is not part of the spec. Far better is https://raw.githubusercontent.com/oslc-op/oslc-specs/cm-v3.0-psd01/specs/cm/change-mgt-spec.html. In this particular case, the fact that this is delivered without content negotiation is a plus - you get the raw source rather than an HTML rendering. 5. Where permanent links will be established to specifications. "Once an open-services.net redirect opens an actual specification, the reader will see the appropriate this, previous and latest OASIS links." The 'latest version' link is the one that concerns me the most - what if the latest is no longer at OASIS, or at least not where OASIS thought it was at that time? Can OASIS guarantee to have a stable URL for 'latest' that always follows the spec wherever it goes in the future? There's already the potential issue about versions of the spec, as opposed to revisions - what will the OASIS 'latest' link for Core 3.0 PSD 01 point to after Core 4.0 is published? 6. Additional components URLs also need to be generated Given the agreement in (3) that relative links are OK, I think we should use those. Nick. From: "Jim Amsden" <jamsden@...> To: oslc-op@... Date: 07/24/2019 08:02 AM Subject: [EXTERNAL] [oslc-op] Please review the agenda for tomorrow's oslc-op meeting Sent by: oslc-op@... Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view -- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575
|
||
|
|
||
|
Re: Please review the agenda for tomorrow's oslc-op meeting
Chet Ensign
Hey Jim, Paul and I are in staff and board meetings this week but on the issue of finalizing the template/style sheets, how about we get on a call together next week and walk through all the remaining questions/issues and close on them together? Will you all have time free? /chet
On Wed, Jul 24, 2019 at 11:01 AM Jim Amsden <jamsden@...> wrote: Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view --
/chet ---------------- Chet Ensign Chief Technical Community Steward OASIS: Advancing open standards for the information society http://www.oasis-open.org Mobile: +1 201-341-1393
|
||
|
|
||
|
2019 Open Standards Cup winners
Chet Ensign
All, I am pleased to announce the winners of the 2019 Open Standards Cup. We had a number of deserving projects and standards this year and all are truly deserving of recognition and applause. One of the fundamental standards powering thousand of IoT networks, MQTT v5.0 added significant new features including enhancements for scalability, improved error reporting, extensibility mechanisms, and performance improvements to support small clients. MQTT is designed to support messaging for devices requiring small code footprints, low power/bandwidth, variable availability, and negotiated delivery guarantees. Category Finalists: 1) Akoma Ntoso Version 1.0 (https://www.oasis-open.org/committees/legaldocml/) 2) Classification of Everyday Living Version 1.0 (https://www.oasis-open.org/committees/coel/) 3) TOSCA Simple Profile in YAML Version 1.2 (https://www.oasis-open.org/committees/tosca/) 4) Universal Business Language Version 2.2 (https://www.oasis-open.org/committees/ubl/) 2019 Outstanding New Initiative OSLC Open Project (https://github.com/oslc-op and public web presence at https://open-services.net/) The OSLC-OP is developing standards, frameworks and test suites for capabilities that enable the development of integrated toolchains supporting software development and life-cycle management. In 2019, they migrated to an Open Project to grow their community and open the work to contributors beyond the boundaries of OASIS. Category Finalists: - OASIS Variability Exchange Language (VEL) TC (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vel) - ODF Advocacy (https://github.com/odf-advocacy) My thanks to the members of the TAB for their consideration and time to select the finalists. /chet ---------------- Chet Ensign Chief Technical Community Steward OASIS: Advancing open standards for the information society http://www.oasis-open.org Mobile: +1 201-341-1393
|
||
|
|
||
|
Please review the agenda for tomorrow's oslc-op meeting
Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view
-- Jim Amsden, Senior Technical Staff Member ELM Quality Manager 919-525-6575
|
||
|
|
||
|
Re: Minutes for 2019-07-18
Nick Crossley <nick_crossley@...>
I have reviewed Andrew's
pull request for ReSpec changes to URI generation, and merged it with my
own changes into master (ReSpec 2.1.4). In doing so, I have restored the
handling of previousMaturity and previousPublishDate - if you set those
conf variables, they will show up in the 'Previous' URIs section of the
header.
Nick. From: "Andrii Berezovskyi" <andriib@...> To: "oslc-op@..." <oslc-op@...> Date: 07/18/2019 08:53 AM Subject: [EXTERNAL] [oslc-op] Minutes for 2019-07-18 Sent by: oslc-op@... Hi,
Please find the minutes from today here: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2019/2019-07-18.md
Please add agenda items for the next meeting here: https://hackmd.io/@driib/oslc-op-minutes/edit?both
Cheers, Andrew
|
||
|
|
||
|
Minutes for 2019-07-18
Hi,
Please find the minutes from today here: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2019/2019-07-18.md
Please add agenda items for the next meeting here: https://hackmd.io/@driib/oslc-op-minutes/edit?both
Cheers, Andrew
|
||
|
|
