search

SamCooper / COMMON_SPEC_RIDS

1 stars 0 forks source link

[Configuration service] import/export XML #92

Closed lacourte closed 5 years ago

lacourte commented 6 years ago

The importXML and exportXML operations allow to create/store a Configuration object from/to an XML representation. The Configuration object may be a ProviderConfiguration or a ServiceConfiguration, that is a COM object. The standardized format to use (cf 2.6) is based on the standardized XML Encoding format, which defines a mapping between MAL objects and XML. A COM object is more or less made of several MAL objects, but no MAL structure groups them all. We may list those required to store the COM object in the Archive service, which must be done in the importXML case. We need at least:

SamCooper commented 6 years ago

Please suggest the structure to use and I will document it

lacourte commented 6 years ago

I am not sure about the domain, instanceId and network. Domain and network are required to create the object in Archive. Should they be provided ? Or should we reuse the domain and network used by Provider service (or by the client of the operation) ? The instanceId could be provided, or be left to the Archive service to allocate. If you have no recommendation about those three fields, I would add them to the structure.

lacourte commented 6 years ago

I suggest them the following MAL::Composite datn type : ComObject | field | type | nullable | comment | | instId | MAL::Long | yes | instance identifier of the COM object | | objectType | COM::ObjectType | no | MAL type of the COM object | | objectDetails | COM::ObjectDetails | no | related and source fields of the COM object | | body | MAL::Element | yes | body of the COM object | | domain | List | no | domain of the COM object | | network | MAL::Identifier | yes | network zone of the COM object |

SamCooper commented 6 years ago

So as I see it, the first two fields (plus the domain entry) replicate the ObjectID structure except that the instId field is nullable, is that correct? We then have the Object Details. An optional network. And then the body.

Is that correct?

I think the network should not be there, that is a messaging thing and not relevant to objects. I also think domain should be removed as domain is specific to a provider, these configurations can be used by multiple providers

That leaves us with the Object id fields and the body, correct?

lacourte commented 6 years ago

Actually the list comes from the parameters of the Archive store call, as we will have to call Archive.store when importing the configuration. About the domain and network stuff I dont know. They are part of the Archive store call, and seem to be used when retrieving objects from Archive. So their value maight be important. If we remove them from the XML, then we may provide a null value for network, but we need to find a value for domain.

SamCooper commented 6 years ago

Ok so we need domain, no problem.

Do you think it would be useful to provide an Annex in the document giving a couple example XMLs?

lacourte commented 6 years ago

What would be great would be for you to give the XML export of example configurations that we would use in the prototyping. That would be useful to me! I remind you that I have no XML/COM translater, and I dont plan to write a full one for the prototyping of Common.

This point set aside, I think it could be useful if you want the people that will use the specification evaluate if this format fits their expected usage. You would give them the opportunity to decide that they prefer a simpler (and thus dedicated) format than the generic one.

apinder commented 5 years ago

I've just noticed we've got a bit of discussion here regarding the XML which I didn't see when I posted https://github.com/SamCooper/COMMON_SPEC_RIDS/issues/101 . I'll keep that issue open and just use it to show the current XML based on our discussion here.

Given the above comments I'll start converting the existing structure into the proposed structure; the existing one doesn't take into account the underlying COM archive structure objects so I'll be adding the ComObject MAL:Composite datatype as above.

To confirm this will be structured as:

| field | type | nullable | comment |
| instId | MAL::Long | yes | instance identifier of the COM object |
| objectType | COM::ObjectType | no | MAL type of the COM object |
| objectDetails | COM::ObjectDetails | no | related and source fields of the COM object |
| body | MAL::Element | yes | body of the COM object |
| domain | ListMAL::Identifier | no | domain of the COM object |

Did we come to a conclusion on whether we'd have a separate ObjectID element to contain the domain, instId and ObjectType?

My thoughts if we were to represent the COM object structure in XML is that we'll need them for the following COM types:

But it depends on whether we have a 1 to 1 mapping between the COM objects and their XML counteraparts.

EDIT: Removed network field

SamCooper commented 5 years ago

I think it makes sense to use ObjectId except when importing as you may not have an ObjectInst Id then?

And I don't think we need network zone?

apinder commented 5 years ago

I've removed the network zone from the COM Object definition. I agree on the ObjectId I like the idea of a 1 to 1 mapping between COM Object types to XML elements as it keeps it clear.

So my suggestion would be to have a COM:ObjectID as:

| field | type | nullable | comment |
| key| COM::ObjectKey | no | Object key holding the domain and instId|
| type| COM::ObjectType | no | ObjectType of the COM Object|

COM:ObjectKey

| field | type | nullable | comment |
| domain| ListMAL:IdentifierList| yes? | The domain|
| instId | MAL::Long | yes | COM inst ID|

The COM::ObjectType would just hold the area, service, version and number as expected.

Then the resulting COMObject type would be:

| field | type | nullable | comment |
| objectId| COM::ObjectId| yes | The object ID of the COM Object|
| body | MAL::Element | yes | body of the COM object |
apinder commented 5 years ago

Hi @lacourte I've updated the XML documents here : https://github.com/SamCooper/COMMON_SPEC_RIDS/issues/101. I've built a rough COM obj -> XML encoder. It would be good if you could have a look over the XML and see if it makes sense. At the moment I've switched them over to using purely generic COM objects so it might be the case that we want a name field on some of the COM Objects rather than just using the ObjectType but really that's just for legilbility of the document itself.

The other question is whether we should have a 'common' area XML namespace for objects like the ConfigurationObjectSet and ServiceKey which are specific to the common area. Also I've set some fields to attributes of XML elements rather than child elements this can be changed if necessary.

lacourte commented 5 years ago

Hi Alex,

you have done a big work with this XML stuff, but I am afraid I have some questions about it.

In the COMObject definition above you have only kept the objectId and body fields. I believe it is just a text cut mistake as in the examples you still have the three fields ObjectId, ObjectBody and ObjectDetails.

In the ObjectBody there may remain some copy/paste errors as well. I have commented that in issue #101. I have also added in a separate comment a discussion about the meaning of compact and complete.

A more global remark relates to the conformance of your proposal with the XML encoding defined in the referenced standard. My initial understanding was that we just had to define a MAL type for the COM Object data, and the ESA prototype of the MAL/XML standard would generate automatically an XML translation. I understand now that the standard is more like a template so you need to define specific schemas for the new MAL types we have to encode. So far so good. However I still believe that there should be a MAL type defined corresponding to the top level XML Object type. I do not find this type in the Common draft standard.

Then you have chosen to "inline" the ConfigurationObjects COM object in the definition of the Object element. This choice has definitely some value. Its main drawback is that if the same COM object is referenced twice, then it will be encoded twice. However it solves issues that would be raised by keeping this field a MAL::Long. I think there is no problem with it, at least when we encode ServiceConfiguration or ProviderConfiguration COM objects.

The last and most complicated point relates to the COM objects than should eventually be referenced by the objInstIds field of the ConfigurationObjectSet structure. I believe the content of those COM objects should be translated in XML in the complete level of export. Should they be "inlined" as the ConfigurationObjects COM object has been inlined? Or should we answer to the difficult question of encoding just the object reference?

lacourte commented 5 years ago

The other question is whether we should have a 'common' area XML namespace for objects like the ConfigurationObjectSet and ServiceKey which are specific to the common area.

I understand that the MAL/XML standard requires such a specific namespace.

Also I've set some fields to attributes of XML elements rather than child elements this can be changed if necessary.

I really don't know for this one. I assume this is define by the specifications, and should be automatically generated by the ESA prototype.

lacourte commented 5 years ago

Hi Alex, following my previous remark I tried to design a generic solution to the mapping issue, but failed. I think there is a defect here in the specifications. However I succeeded in implementing a specific solution. So you will find in the source code I pushed on BitBucket a set of MAL types in the CommonPrototype area. They are Inline prefixed versions of the Common COM types. As you will see I have followed your idea of inlining the referenced objects. Those types are assumed to be transformed in XML according to the mapping defined in the MAL/XML standard. For the XML version I have tried to follow the pattern you described in the examples. I will push the new version on the other thread. Please comment if you think this does not conform to the MAL/XML mapping.

SamCooper commented 5 years ago

Closing