[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 238 proposal v2
I have uploaded v2 of the 238 proposal at: http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/40315/sca-assembly-1.2-spec-wd01-issue238v2.pdf and http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/40314/sca-assembly-1.2-spec-wd01-issue238v2.doc If you don't want to be confused with spurious diffs from crossref updates please look at the PDF and not the Word doc. The PDF version contains pages only from sections 8, 9 and Appendix A. These three sections are the only ones that are relevant to the proposal. If you are curious as to where the other spurious changes in v1 came from: All of them are from cross-reference updates. 4 of those occurred because they used the wrong cross-reference (a cut-and-paste error that is also present in WD01). I fixed those 4 cases. The other cases, I tried to fix them, but Word keeps updating the auto-generated cross-reference text (with identical text) even after I accept the new changes -- I can't figure out why Word keeps doing that. I tried using OOo, but that made the problem even worse. The diffs showing up in the example Snippet references weren't worth fixing, since 1.2-wd01 is a branch of 1.1-cd04 and at some point we'll have to migrate to 1.1-cd06 (or later). In any case, till we migrate to the latest version of 1.2, the best solution for now I think is to look at sections 8/9 and Appendix A as those are the only sections relevant to this proposal. Here is the explanation for the proposal (the actual text changes are small, but below is the rationale for those changes): There are three syntactic uses of eventType (or some various of it): (a) in the EDL, (b) in the event instance/message, (c) in the filter (a) The EDL defines a QName for the event type and points to the associated XSD. If you are not using XSD, there will some other way to define the event type (the example that has been discussed in the past is a fully qualified Java class name). This is the EDL eventtype. In the proposal it is called sca:eventTypeXSD. If we use the EDL defined by W3C WS-RA then we won't be doing any work wrt this. b) the event instance *may* contain metadata for event type (such as a header). For example, there may be a eventType header. Note the spec is silent on this. c) The filters on a consumer/channel may specify an filter based on event types. This is the one thing that is specified by our spec and will persist even if we adopt WSRA's EDL. The filter schema consists of two parts: eventType -- an abstract element (substitution group head) eventType.sca -- concrete element that uses our EDL (or will point to WSRA's EDL, if adopted) and is part of the substitution group. This requires that the definition of the event type must use XML schema as defined by our spec (currently) or WS-RA, if adopted. One can extend this by creating eventType.java or eventType.myFavoriteExtension It is important to note that the eventTypeXSD syntactic element defined by the EDL (in (a) above), cannot be used for filtering. The filtering element points to one or more QNames/namespaces used by the EDL. The structure of the elements is very different. This is the main error pointed out by issue 238 wrt 1.2-wd01 that this proposal fixes. An example: (a) EDL -- <eventDefinitions targetNamespace="http://example.org/edl" ...> <eventTypeXSD name="PrinterEvent" element="foo:PrinterData"/> </eventDefinitions> (b) Event instance, if it used XML (made up example) -- <foo:PrinterData ...> <foo:header> <foo:eventType>...</foo:eventType> ... </foo:header> <foo:body> ... </foo:body> </foo:PrinterData> (c) filter on the event type PrinterEvent defined by the EDL above -- <filters xmlns:ex="http://example.org/edl" ...> <eventType.sca qnames="ex:PrinterEvent" /> </filters> -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]