[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca-comment] nested_property_name in get_property and get_attribute
|
Chris, TMForum publish standard schemas for many concepts used by communications service providers at
tmforum-rand/schemas: This directory contains the collection of JSON Schema files that define the entities used within the TM Forum Open-API Catalog (github.com).
At first read these may appear to be simplistic but they are expected to be extended to add situation specific content. For example MEF
MEF - Empowering Enterprise Digital Transformation extend them for certain telecom technologies. TOSCA templates may be passed a JSON which conforms to one of these schemas but may need to access a leaf value. A couple of somewhat contrived examples are: A TOSCA node deployment may need to use a service name or a customer name in its identifier.
A service request might include a size or availability target which influences how many TOSCA nodes should be deployed.
Paul Jordan This email contains information from BT that might be privileged or confidential. And it's
only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks. We monitor our email systems and may record all our emails. From: Chris Lauwers <lauwers@ubicity.com>
The philosophy behind the Json and Xml string subtypes was that these types would be just like strings, but with extra schema validation. Or, said a different way, the schema was only intended to be used for validation,
not as a mechanism for extracting individual sub-fields from the json-encoded string. For purposes of TOSCA processing, these values would be opaque. Paul, I would be interested in the use case where you need to inspect the internals of these string values.
Thanks, Chris From:
tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org>
On Behalf Of Tal Liron I agree that we can do better. We've discussed aspects of this from two approaches: 1) The json and xml types (which I think we've since removed?) are textual types that have some kind of schematics. But the whole approach is awkward, as it involves embedded text in TOSCA, which would of course not be
directly "nestable" with something like get_property. And text-embedding is a whole can of worms: encoding issues, formatting, and many different ways to specify and retrieve schemas. I don't think this is the right way to go. 2) We've raised the question a few times as to whether TOSCA needs an "any" built-in type. The idea is that "any" would be anything that can be expressed in YAML. In my own work I tend to call this kind of data
ARD: Agnostic Raw Data. There are a few gotchas to be aware of, but I'm confident it's possible to specify it clearly for TOSCA, and it should be easy to implement by any processor (the processor is already parsing YAML), and also easy to translate into
a string for transfer (the gotchas have to do with round-trips). When properly specified, it would then be possible to have a well-defined get_property that could nest into dicts and arrays (grammar that should still be improved by something like XPath). In short, something I would definitely want us to tackle for 2.0. On Wed, Feb 3, 2021 at 3:53 AM <paul.m.jordan@bt.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]