TOSCA Namespaces for tosca-nfv-profile

Slides:



Advertisements
Similar presentations
DC8 Registries Breakout. Goals of the session Discuss and clarify : Requirements for registry Framework for policy Relate issues raised to EOR prototype.
Advertisements

Registry breakout group DC-8, National Library of Canada 5 October 2000.
1 CP3024 Lecture 9 XML revisited, XSL, XSLT, XPath, XSL Formatting Objects.
Web Ontology Language for Service (OWL-S). Introduction OWL-S –OWL-based Web service ontology –a core set of markup language constructs for describing.
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006 draft-ietf-sidr-res-certs-01 Geoff Huston Rob Loomans George Michaelson.
RDF Data Sources (keyword textbox) Search RDF Data Sources: LOM Binding Schemas (keyword textbox) Search XML Bindings: Dublin Core Application Profiles.
Why XML ? Problems with HTML HTML design - HTML is intended for presentation of information as Web pages. - HTML contains a fixed set of markup tags. This.
Conformance Mark Skall Lynne S. Rosenthal National Institute of Standards and Technology
TOSCA Monitoring Working Group Status Roger Dev June 17, 2015.
WSON Routing WG Drafts 1.Routing and Wavelength Assignment Information Model for WSON 2.General Network Element Constraint Encoding for GMPLS Controlled.
© 2012 The MITRE Corporation. All rights reserved. For internal MITRE use 13 June 2013 Meeting #3 hData Record Format Taskforce 1 © 2012 The MITRE Corporation.
KMIP 1.3 Deprecation February 20, Deprecation 5.1 KMIP Deprecation Rule Items in the normative KMIP Specification [KMIP-Spec] document can be marked.
Abstract Processes in BPEL4WS Tony Andrews Software Architect Microsoft.
TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,
METS Application Profiles Morgan Cundiff Network Development and MARC Standards Office Library of Congress.
Internet & World Wide Web How to Program, 5/e. © by Pearson Education, Inc. All Rights Reserved.2.
XML Schema Definition (XSD). Definition of a Schema It is a model for describing the structure and content of data The XML Schema was developed as a content.
Lecture 23 XQuery 1.0 and XPath 2.0 Data Model. 2 Example 31.7 – User-Defined Function Function to return staff at a given branch. DEFINE FUNCTION staffAtBranch($bNo)
Describing resources II: Dublin Core CERN-UNESCO School on Digital Libraries Rabat, Nov 22-26, 2010 Annette Holtkamp CERN.
TOSCA V1.1: Variants of Collections of Specs. Spec Structure – Variant A The XML Simple Profile is a subsetting of the V1.1 spec but compliant with the.
Interop SC 02/03/2016. Agenda Jacques feedbacks Contribution process improvements proposal 2.
VNF Package CSAR Format Tal Halfon, Amdocs Andrei Kojukhov, PhD, Amdocs Aug 3, 2017.
Logical Database Design and the Rational Model
VNF Package CSAR Format Tal Halfon, Amdocs Andrei Kojukhov, PhD, Amdocs Aug 3, 2017.
VNF Package CSAR for ONAP Release 2 – adding Telco grade features Andrei Kojukhov, PhD, Amdocs Oct 6, 2017.
ONAP SDC TOSCA Import Gap Analysis
ONAP Information Model and Data Model
VNFD and NSD modeling: Rel2 Thinh Nguyenphu, Nokia thinh
Approach to finalize the TOSCA NFV profile
OASIS TOSCA Report for December ONAP Event
Clarification of CSAR format Thinh Nguyenphu, Nokia thinh
TOSCA Namespaces for tosca-nfv-profile
Critical issues with TOSCA NFV profile direction
DF design as a node type.
OASIS TOSCA Report for December ONAP Modeling Workshop
TOSCA Namespaces Explained
Capability issues Shitao li.
OASIS TOSCA Report for December ONAP Event
DF design as a node type (output by Chris and shitao)
TOSCA NFV profile: short vs long-term approach
DF design as a node type (output by Chris and shitao)
NFV & SDN adhoc Progress
Enhancements for Simple YAML Profile v1.2
Artifact Properties Use cases and Examples to demonstrate the need of artifact properties July 2018.
TOSCA Namespaces Explained
SwImageDesc Shitao li.
Remain issues
Instance Model Structure
ONAP modeling report shitao.
VDU proposal comparison
DF design as a node type (output by Chris and shitao)
Post WG LC NMDA datastore architecture draft
Deployment Flavour as VNF Capability: Alt1_r2
Discussion of Publishing CSD03 version of NFV Profile
JAR Desc CSAR Notes A package file format typically used to aggregate many Java class files and associated metadata and resources (text, images, etc.)
NFV adhoc Shitao li.
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006
PAR Review - Agenda and Meeting slides - March 2016
This presentation document has been prepared by Vault Intelligence Limited (“Vault") and is intended for off line demonstration, presentation and educational.
Open Source Projects Collaborations with ONAP
Global Types – Open-O spec versus TOSCA NVF Profile
NFV adhoc Shitao li.
TOSCA v2.3 Naming Decisions
TOSCA v1.3 Deprecated Features and Non-Backward-Compatible Changes
NFV adhoc Shitao li.
VNF Package CSAR Format Tal Halfon, Amdocs Andrei Kojukhov, PhD, Amdocs Aug 3, 2017.
New Applications Modeled
Entity vs Datatype.
Brief update and critical issues
Task 55 Scope – TOSCA Profile
Presentation transcript:

TOSCA Namespaces for tosca-nfv-profile Shitao li

Namespace discussion in TOSCA 2017-11-02 - TOSCA Namespacing Explained - Draft.pptx

Main issues need to consider in tosca-nfv-profile tosca_definitions_version ? Namespace Alias ? Namespace URI ? Namespace Prefix ?

1, tosca_definitions_version Can we suggest in tosca-nfv-profile that the “tosca_definitions_version ” keyname needs to always follow the same processing procedure in tosca-simple-profile-yaml? The only valid values now for “tosca_definitions_version” in tosca-nfv-profile are “tosca_simple_yaml_1_2”, “tosca_simple_yaml_1_1” and “tosca_simple_yaml_1_0 (namealias representing a TOSCA YAML Simple Profile specification)

2, Namespace Alias This is related to the first issue for “tosca_definitions_version” keyname Namespace alisa : In the TOSCA Simple Profile, TOSCA Service Templates MUST always have, as the first line of YAML, the keyword “tosca_definitions_version” with an associated TOSCA Namespace Alias value. If the first suggestion is yes, Option 1: does not define namespace alias in tosca-nfv-profile, Delete the namespace alias in tosca-nfv-profile Option 2: define a new namespace alias, but clearly indicate that this namespace alias shall not be used as a valid value of “tosca_definitions_version”, it is only used for qualified type names or URI, for example, tosca_simple_nfv_1_0:nfv.nodes.Vdu There is a defined namespace Alias in tosca-nfv-profile, that is “tosca_simple_profile_for_nfv_1_0”, if we keep it as it is, some explanation of its usage should be added. If the first suggestion is no, ?

3, Namespace URI There is a defined namespace URI in tosca-nfv-profile. Do we want to keep it, or change it to another one?

Namespace Prefix Namespace Prefix has not defined in tosca-nfv-profile right now. As suggested from Matt’s slide, Vender specific type defines and namespace prefix should be allowed, but from standard perspective, a standard prefix for the basic types of NFV applications should be given. It is suggested to define a namespace prefix in tosca-nfv-profile for interoperability purpose. For example: NFV: tosca.nodes.nfv.cpd

Other issues?

Backup

Profiles & Conformance What is intended Approved, TOSCA Namespace URI - define a TOSCA-approved Namespace URI for the Profile’s Types that matches spec. version i.e., for default/target namespace Extensibility via Profile Types - define new Types needed to model the subject area for the Profile These Types would be bound to the TOSCA approved Namespace URI for the Profile Simplified Import – allow profile types to be imported “on-top” of TOSCA Simple Profile base types Ideally, “import” of a Profile’s Types should be accomplished with one (1) line of YAML Namespace Prefix: possible a reserved Namespace Prefix for the Profile Note: TOSCA base profile version compatibility is an issue to discuss What is not intended No new Grammar - Profiles are not allowed to define new grammar Should not define new “keywords” for TOSCA entities Profile WGs should submit uses cases to the Simple Profile WG that express needs in the base profile Limited ability to describe additional Requirements (prose) on individual Types e.g., describe special treatment of property/attribute values Perhaps “constraints” grammar is not expressive enough? or one Property value depends on another? Note: the Profile WG should try to submit uses cases to Simple Profile WG when they find limitations that could be fixed via the core grammar