RE: [tosca] Groups - 2017-11-07 - Simple Profile WG - Meeting Notes.html uploaded

["Matt Rutkowski" <mrutkows@us.ibm.com>]

Hi Steve,

Allow me to try and summarize what changes
to expect (numbered 1,2 and 3 about 2/3rds down in the meeting notes):

1. (new top-level Service Template) key to declare URI 
   • to be the "targetnamespace" for types declared within the same template; as indicated on slide 10 of the PPTX on namespaces:
     • Using XML terms we are missing an ability for a Service Template author to define a target Namespace URI and default Namespace for local, unprefixed declarations: <xs:schema targetNamespace="http://myURI.org/blah/etc/”        
   • and perhaps also the "default" namespace: xmlns="http://myURI.org/blah/etc/">
2. (new top-level Service Template) key to declare (the) optional default prefix to use (to represent the declared URI in an instance document)
   • if one is not provided by another ServiceTemplate (including the declaring template) on the "import" statement.
3. means to import by URI

Given these changes, this should enable
us to do many of things need... as for my responses to your questions:

#1
Today, the current import definition
always requires a file URI which is the YAML file that contains the custom
type definitions.
Is this changing? 
Or Is it just a matter of keeping this
method but specifying if it is a local file (stored in the CSAR or orchestrator
repository) or remotely-accessible file on the Internet?
If it is for a remotely-accessible file
on the Internet, is it just a matter of using a URL pointing to a “well-known”
location + YAML file name where the standard ETSI/NFV YAML file resides?

The current grammar should remain the
same and function as it does today.  We just intend to look at adding
import by URI above (#3) as perhaps another means (and I am not convinced
that is valid and deserved some more discussion).  

As "import" in other languages
do NOT do this. it SHOULD be valid to reference another Service template
as a relative path/file (in CSAR) <OR> as a fully qualified URL (accessible
on the internet).  If that is not clear, we need to make it clear....
referencing by URI seems more of an "internal" processing convenience
(not something users will ever use or need).

#2
Should we promote the use of qualified
Type URIs within the custom type definitions file when it is provided by
ETSI or ONAP knowing namespace is “required” in this case?
For instance nfv:nfv.nodes.Vdu where
nfv is the namespace prefix for NFV profile and nfv.nodes.Vdu is the Type
URI for VDU node type.
This way the import definition does
not need to specify the namespace_prefix.
The author of the import definition
can always “override” the already-provided namespace prefix with its
own namespace_prefix.

It should be best practice for anyone
producing their own set of Types to provide a ServiceTemplate that declares
their targetnamespace (as we intend to add as work item #1) and allow them
to optionally declare a prefix (which can be overridden by the importing
template/document instance using those types).

It should also be best practice for
Type designers to also clearly use qualified type names when subclassing
types they are sensitive to changes on; that is, create an import to the
exact version they need to use/reference and associate a unique prefix
for that set of types. Then they should clearly use the prefix to qualify
the types they are building on which are bound to a specific version.

My opinions...

Kind regards,
Matt 




From:      
 Steve Baillargeon <steve.baillargeon@ericsson.com>
To:      
 Matthew Rutkowski <mrutkows@us.ibm.com>,
Chris Lauwers <lauwers@ubicity.com>, Luc Boutier <luc.boutier@fastconnect.fr>
Date:      
 11/07/2017 03:30 PM
Subject:    
   RE: [tosca]
Groups - 2017-11-07 - Simple Profile WG - Meeting Notes.html uploaded

---

Resending.
Adding Chris and Luc
Removing tosca list since it seems the
server is blocking the email.
 
-Steve
 
From: Steve Baillargeon 
Sent: Tuesday, November 07, 2017 4:20 PM
To: 'Matthew Rutkowski' <mrutkows@us.ibm.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - 2017-11-07 - Simple Profile WG - Meeting
Notes.html uploaded
 
Hi
Thank you for the great discussion today.
 
Is it possible to summarize the proposed
changes if any to the import definitions for importing custom types defined
by “standard bodies” like ETSI and ONAP?
 
#1
Today, the current import definition always
requires a file URI which is the YAML file that contains the custom type
definitions.
Is this changing? 
Or Is it just a matter of keeping this
method but specifying if it is a local file (stored in the CSAR or orchestrator
repository) or remotely-accessible file on the Internet?
If it is for a remotely-accessible file
on the Internet, is it just a matter of using a URL pointing to a “well-known”
location + YAML file name where the standard ETSI/NFV YAML file resides?

 
#2
Should we promote the use of qualified
Type URIs within the custom type definitions file when it is provided by
ETSI or ONAP knowing namespace is “required” in this case?
For instance nfv:nfv.nodes.Vdu where nfv
is the namespace prefix for NFV profile and nfv.nodes.Vdu is the Type URI
for VDU node type.
This way the import definition does not
need to specify the namespace_prefix.
The author of the import definition can
always “override” the already-provided namespace prefix with its own
namespace_prefix.
 
-Steve B
 
 
 
From: tosca@lists.oasis-open.org[mailto:tosca@lists.oasis-open.org]
On Behalf Of Matthew Rutkowski
Sent: Tuesday, November 07, 2017 1:04 PM
To: tosca@lists.oasis-open.org
Subject: [tosca] Groups - 2017-11-07 - Simple Profile WG - Meeting
Notes.html uploaded

Document Name: 2017-11-07 - Simple Profile WG - Meeting Notes.html

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Mr. Matthew Rutkowski
Group: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder: Meeting Notes
Date submitted: 2017-11-07 10:03:18