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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

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


Subject: RE: Tosca.meta block 0 clarification


Hi,

 

Good discussion. Regarding the validity of SOL004, I would like to give my view and summarize the status.

 

We introduced the additional custom fields in the TOSCA.meta file in SOL004 Rel-2, which uses TOSCA 1.2. We had to put them in block 0 because other blocks had to start with

Name: <path_name>.

 

Besides, blocks other than 0 were meant to describe metadata about other particular files.

 

Thus, I think SOL004 Rel-2 is correct.

 

SOL004 Rel-3 uses TOSCA 1.3. The problem, as some of you have pointed out, is that the CSAR specification in  1.3 is not self-contained unfortunately, so one could interpret that the rules about blocks other than 0 which are specified in 1.0 still are valid, with the exception that now  custom fields are now explicitly allowed.

 

TOSCA 2.0 is meant to be self-contained. There is no specification about starting the block with

Name: <path_name>

 

so that first line is not required.

 

I agree that TOSCA 1.3, in spirit, has the same behaviour regarding TOSCA.meta as in TOSCA 2.0, although not fully spelled in the spec.

 

Thus I guess we should change SOL004 Rel-3 to place the custom fields in block 1.

 

Best regards,

Arturo

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Friday, August 7, 2020 6:19 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: [tosca] RE: Tosca.meta block 0 clarification

 

I think the language in 1.3 (and earlier) makes it clear that custom fields in block 0 are not allowed (it says that custom fields are only allowed in âfurther blocksâ). I donât believe we should re-open this for discussion.

 

Thanks,

 

Chris

 

 

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Thursday, August 6, 2020 9:15 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: Re: Tosca.meta block 0 clarification

 

Hi Gabor,

 

Yes, here is the right link also: https://docs.oasis-open.org/tosca/TOSCA/v2.0/TOSCA-v2.0.html

 

BR/C

 

From: "Marton, Gabor (Nokia - HU/Budapest)" <gabor.marton@nokia.com>
Date: Thursday, 6 August 2020 at 18:10
To: Calin Curescu <calin.curescu@ericsson.com>, Chris Lauwers <lauwers@ubicity.com>
Cc: "Nguyenphu, Thinh (Nokia - US/Dallas)" <thinh.nguyenphu@nokia.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "Nemeth, Denes (Nokia - HU/Budapest)" <denes.nemeth@nokia.com>
Subject: RE: Tosca.meta block 0 clarification

 

Thanks Calin,

 

but the links you sent refers to v1.2, not to v2.0.

 

I have an earlier draft of v2.0 (Revision 11A, 20 April 2020). I guess you meant this section:

 

5.2 TOSCA Meta File

A TOSCA meta file consists of name/value pairs. The name-part of a name/value pair is followed by a colon, followed by a blank, followed

by the value-part of the name/value pair. The name MUST NOT contain a colon. Values that represent binary data MUST be base64 encoded.

Values that extend beyond one line can be spread over multiple lines if each subsequent line starts with at least one space. Such spaces are

then collapsed when the value string is read.

<name>: <value>

Each name/value pair is in a separate line. A list of related name/value pairs, i.e. a list of consecutive name/value pairs is called a block.

Blocks are separated by an empty line. The first block, called block_0, contains metadata about the CSAR itself and is further defined below.

Other blocks may be used to represent custom generic metadata or metadata pertaining to files in the CSAR. A TOSCA.meta file is only required

to include block_0.

 

I agree, that ambuguity has gone.

 

Greetings,

 

GÃbor

 

 

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Thursday, August 6, 2020 10:32 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: Re: Tosca.meta block 0 clarification

 

Hi Gabor,

 

Yes, adding the custom key-value pairs in a new block should be fine from v1.3 and v2.0 on. As Li Shitao points out, the standard does not specifically allow or disallow the custom key-value pairs in block 0, but specifically allows them in the further blocks. I think the easiest and best is to put the custom key-value pairs in further blocks, but we can discuss in the TOSCA language WG to specifically allow them in block 0 if ETSI can provide a strong argument for that.

 

Regarding your question on âentry syntax of the TOSCA.meta fileâ the meaning is how the key-value pair is written, not the constraint for the first entry (think all entries syntax). But since v1.3 is still defined with reference to TOSCA 1.0 in XML it has this problem. In Tosca 2.0 we want to clean up all references to TOSCA 1.0 so we define all in the text, and the ambiguity goes away. Please take a look at the 2.0 draft formulation here:

http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html

 

BR/C

 

From: "Marton, Gabor (Nokia - HU/Budapest)" <gabor.marton@nokia.com>
Date: Thursday, 6 August 2020 at 10:18
To: Calin Curescu <
calin.curescu@ericsson.com>, Chris Lauwers <lauwers@ubicity.com>
Cc: "Nguyenphu, Thinh (Nokia - US/Dallas)" <
thinh.nguyenphu@nokia.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "Nemeth, Denes (Nokia - HU/Budapest)" <denes.nemeth@nokia.com>
Subject: RE: Tosca.meta block 0 clarification

 

Oops, sorry, my bad! Section 6.2.1 allows populating further blocks with custom key-value pairs (not further custom key-value pairs in block_0).

 

So, it seems like SOL 004 needs to prescribe the empty line to be put before the ETSI-specific key.

 

And still, the text in 6.2.1 is ambiguous: âpopulate further blocks in the TOSCA.meta file with custom key-value pairs that follow the entry syntax of the TOSCA.meta fileâ. Does the following rule of TOSCA v1.0 belong to the said entry syntax: âThe first line of a block (other than block_0) MUST be a name/value pair that has the name âNameâ and the value of which is the path-name of the file described [â]â?

 

Greetings,

 

GÃbor

 

From: Marton, Gabor (Nokia - HU/Budapest)
Sent: Thursday, August 6, 2020 9:52 AM
To: Calin Curescu <
calin.curescu@ericsson.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <
thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: RE: Tosca.meta block 0 clarification

 

Thanks a lot, Calin, for the clarification.

 

However, while trying to conclude about SOL 004, I found an interesting thing in TOSCA v1.3---it slipped my attention till now:

 

6.2.1 Custom keynames in the TOSCA.meta file

Besides using the normative keynames in block_0 (i.e. TOSCA-Meta-File-Version, CSAR-Version,

Created-By, Entry-Definitions, Other-Definitions) users can populate further blocks in the TOSCA.meta file with custom key-value pairs that follow the entry syntax of the TOSCA.meta file, but which are outside the scope of the TOSCA specifications.

 

Nevertheless, future versions of the TOSCA specification may add definitions of new keynames to be used in the TOSCA.meta file. In case of a keyname collision (with a custom keyname) the TOSCA specification definitions take precedence.

 

To minimize such keyname collisions the specification reserves the use of keynames starting with âTOSCAâ and âtoscaâ (the strings within, but not including, the double quotation marks). It is recommended as a good practice to use a specific prefix (e.g. identifying the organization, scope, etc.) when using custom keynames.

 

So, if SOL 004 explicitly references TOSCA v1.3 and the above section (now it only refers to TOSCA v1.1), then it should be fine and safe.

 

Do you agree with this conclusion?

 

(Otherwise, if the above section did not exist, we would be in trouble with SOL 004, and the empty line would not resolve it either, because the base specification TOSCA v1.0 says: âThe first line of a block (other than block_0) MUST be a name/value pair that has the name âNameâ and the value of which is the path-name of the file described [â]â).

 

Greetings,

 

GÃbor

 

 

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Thursday, August 6, 2020 7:13 AM
To: Marton, Gabor (Nokia - HU/Budapest) <
gabor.marton@nokia.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <
thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: Re: Tosca.meta block 0 clarification

 

Hi Gabor, Denes,

 

As it is now, the standard only allows custom key-value pairs in other blocks than block 0. In TOSCA v2.0 this is specification is kept.

So yes you are right, SOL004 is not legal, you need an empty line before the non-standard keynames, signifying a new block.

 

BR/Calin

 

From: "Marton, Gabor (Nokia - HU/Budapest)" <gabor.marton@nokia.com>
Date: Wednesday, 5 August 2020 at 17:35
To: Chris Lauwers <
lauwers@ubicity.com>, Calin Curescu <calin.curescu@ericsson.com>
Cc: "Nguyenphu, Thinh (Nokia - US/Dallas)" <
thinh.nguyenphu@nokia.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "Nemeth, Denes (Nokia - HU/Budapest)" <denes.nemeth@nokia.com>
Subject: RE: Tosca.meta block 0 clarification

 

Hi Calin,

 

what is your standpoint in this question?

 

In case it is not legal to use non-standard keynames in block 0, SOL 004 is not legal either.

 

Greetings,

 

GÃbor

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Thursday, July 23, 2020 9:56 PM
To: Calin Curescu <
calin.curescu@ericsson.com>
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <
thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Subject: [tosca] RE: Tosca.meta block 0 clarification

 

Hi Denes,

 

I assume this email was intended for Calin? Calin has contributed the TOSCA v2.0 text defining the updated CSAR format, so he is in the best position to respond. That said, I believe it is not legal to use non-standard keynames in block 0. Calin, do you have a different understanding?

 

Thanks,

 

Chris

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Nemeth, Denes (Nokia - HU/Budapest)
Sent: Tuesday, July 14, 2020 10:37 PM
To:
tosca@lists.oasis-open.org
Cc: Nguyenphu, Thinh (Nokia - US/Dallas) <
thinh.nguyenphu@nokia.com>
Subject: [tosca] Tosca.meta block 0 clarification

 

Dear Colin

 

After reading the Tosca 1.x and the Tosca 2.0 draft I am not able to deduct if it is allowed to populate the block 0 with additional keys or only the other blocks may be populated with additional key-value pairs. The current draft states the following:

 

The first block, called block_0, contains metadata about the CSAR itself and is further defined below. Other blocks may be used to represent custom generic metadata or metadata pertaining to files in the CSAR.

 

Besides using the normative keynames in block_0 (i.e. CSAR-Version, Created-By, Entry-Definitions, Other-Definitions) users can populate further blocks in the TOSCA.meta file with custom key-value pairs that follow the entry syntax of the TOSCA.meta file, but which are outside the scope of the TOSCA specification.

 

Would it be possible to add a clarification sentence into the specs to define if extension of the block 0 is allowed or not.

 

Cheers Denes

 



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