Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Named Element 'ExtensionAttributes' of Type any #1014

Open
duglin opened this issue May 9, 2022 · 15 comments
Open

Named Element 'ExtensionAttributes' of Type any #1014

duglin opened this issue May 9, 2022 · 15 comments

Comments

@duglin
Copy link
Collaborator

duglin commented May 9, 2022

Discussed in https://github.com/cloudevents/spec/discussions/1012

Originally posted by JimWeier-VeteransUnited May 9, 2022
To enable Back end Systems that Validate XML payloads against given Schemas it would be Nice to have an XML Element Name Extension Attributes of Type Any, So the Schema Validators will ignore any child following it Otherwise if you dont create, a schema would have to be created/Modified every time a new element is added as an extension

@duglin
Copy link
Collaborator Author

duglin commented May 9, 2022

Can't people just put an xs:any at the end of their schema for the current list of CE elements?
https://www.w3schools.com/xml/schema_complex_any.asp

@JimWeier-VeteransUnited

The Elements that are extensions would need to go under the ANY Node as child elements, to work, And this is what I am suggesting we adopt. If you simply add a Single Node of type Any as a child of the Root Node, then add other nodes a siblings under it they will fail Schema Validation, They MUST be Child Elements of the Any Node

@duglin
Copy link
Collaborator Author

duglin commented May 11, 2022

thanks for the reminder... been way too long since I've played with XML :-)

@JemDay thoughts?

@JemDay
Copy link
Contributor

JemDay commented May 26, 2022

I really need to work on the general Schema for the CE structure .. I'd like to defer this particular issue until we have that to prove that there's a problem.

My question would be .. forgetting XML for the moment, what do these extensions represent from a CE information model perspective ?

@duglin
Copy link
Collaborator Author

duglin commented May 27, 2022

They're just sibling attributes to the CE defined ones. We tried to have them be treated just like the optional CE defined attributes.

@JemDay
Copy link
Contributor

JemDay commented May 27, 2022

Siblings of the parent ‘event’ yes - I think we have that covered already.

Siblings of a CE Attribute .. I don’t think that would work …

maybe I’m misunderstanding

@duglin
Copy link
Collaborator Author

duglin commented May 27, 2022

Since you said to ignore xml, here's the json version from the spec:

{
    "specversion" : "1.0",
    "type" : "com.github.pull_request.opened",
    "source" : "https://github.com/cloudevents/spec/pull",
    "subject" : "123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "text/xml",
    "data" : "<much wow=\"xml\"/>"
}

They're sibling attributes to me.

@JimWeier-VeteransUnited
Copy link

Just a comment, I know you said forget XML, Should you at least consider XML because for consistency sake your above example wont work for XML if you want to validate against a particular Standard Schema, Unless Everyone XML will have nodes named
comexampleextension1 and comexampleothervalue... If you would consider XML for just a second AND consider Consistancy Sake, Would it be better to do something like
{
"specversion" : "1.0",
"type" : "com.github.pull_request.opened",
"source" : "https://github.com/cloudevents/spec/pull",
"subject" : "123",
"id" : "A234-1234-1234",
"time" : "2018-04-05T17:31:00Z",
"extension":{
"comexampleextension1" : "value",
"comexampleothervalue" : 5
},
"datacontenttype" : "text/xml",
"data" : "<much wow="xml"/>"
}
And then in XML you would define extension as a type any ..... Just food for thought

@JemDay
Copy link
Contributor

JemDay commented Jun 1, 2022

I'd prefer to shelve this until we (or I) have produced a decent XML Schema ...

Ideally these extension attributes would be an XS:any but with a constrained set of 'types' - that's what I'm mentally struggling with ;-)

@JimWeier-VeteransUnited
Copy link

In XML you cant declare any element of type Any and then Constrain it it, It would be a contradiction to its definition "xsd:any> XML schema element to describe a section of an XML document with undefined content".. The discussion point was really to be that when you define the Json event, you need to be mindful of XML and other formats as you create them for consistency sake..
In doing so you should be able to go from One format to the other without much thought... I currently work in an Environment where I receive JSON, convert to XML, SAP, EDI, and many other formats and Vice versa, When a "standard" a particular message in say JSON is completely different then the same Message in XML , It creates work and overhead... If you take a look at MISMO or ACORD, Their standards are very compatible across Markup languages (XML,JSOn,EDI)... Hopefully you will do the same

@duglin
Copy link
Collaborator Author

duglin commented Jan 19, 2023

@JemDay are you still hoping to do an XML schema?

@JemDay
Copy link
Contributor

JemDay commented Jan 24, 2023

I haven't sat down to try and create a fully-fledged schema yet .. I will admit to being a bit jaded in this area but where ei was getting caught up before was that an XSD really wants to know the xml element names in advance (which we don't know) and the only way out of that is an XS:any which is to loose to be of use.

I don't know of a way in XML Schema to say ... ".. the following elements are named according to this pattern (eg [a-z0-9]+ )and must have an xsi:type from this defined list"

@github-actions
Copy link

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

@duglin
Copy link
Collaborator Author

duglin commented Jul 6, 2023

@JemDay any thoughts on what to do about this one?

@github-actions
Copy link

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants