Open duglin opened 2 years ago
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
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
thanks for the reminder... been way too long since I've played with XML :-)
@JemDay thoughts?
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 ?
They're just sibling attributes to the CE defined ones. We tried to have them be treated just like the optional CE defined attributes.
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
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.
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
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 ;-)
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
@JemDay are you still hoping to do an XML schema?
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"
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
.
@JemDay any thoughts on what to do about this one?
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
.
Discussed in https://github.com/cloudevents/spec/discussions/1012