forked from TAXIIProject/java-taxii
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO.txt
166 lines (136 loc) · 7.26 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
[JJ 10 Feb 2015.
DEPRECATED!!!
Move to-do items to GitHub. I went through and marked the progress on all
the items below.]
ROADMAP
=========
0.1
TAXII XML Message Binding Spec 1.1
[Done]- Create messages programmatically
[Done] + Move TaxiiXml up a level so that it can be factory for 1.1 and 1.0 XML
[Done]- Marshal/unmarshal messages
[Done]- Marshal/unmarshal content blocks (to support content-block nesting)
[Done]- add additional conformance checks using Schematron. Translate the Schematron
into XSLT and bundle the XSLT in with java-taxii.
0.2
TAXII Default Query Spec 1.0
[Done]- Add support for Default Query Format and associated structures and messages
bindings.
0.3
TAXII HTTP Protocol Binding Spec 1.1
[Done]- client-side interactions with server, using HTTP Protocol Binding
.
.
.
1.1.0
- Any other features needed to reach parity with libtaxii WRT TAXII 1.1
post-1.1.0
[Done]- Add support for TAXII 1.0.
[Added GitHub issue]- Add support for JSON Message Binding.
[Added GitHub issue]- add support for creating and validating XML Signatures using Java XML Digital
Signature API
Things to check on marshalling/API usage in unit tests
=======================================================
[I don't think this needs to be done. The JAXB mapping tool handles mixed
content. I don't think we need explicit tests to ensure it works.]
* mixed content in Extended Header,
Status Details,
Discovery_Response/Service_Instance/Supported_Query,
Subscription_Parameters/Query,
Poll_Parameters/Query,
Content_Block/Content
[Done. There is StatusTypeEnum in the 1.1 schema & generated code]* @status_type a union between xs:string and xs:anyURI - make sure constants are available
for known status types
[The dateTime requirements in the spec seem unnecessary. And the pattern in the schema appears broken.] * Check javax.xml.datatype.XMLGregorianCalendar, the default binding for xs:dateTime.
Does it always map to dateTime values that are valid according to the regex for
TimestampLabelType in the schema? If not, need to do a custom mapping so that
only valid timestamps are created via the API.
Things to check on unmarshalling/API usage in unit tests
===========================================================
[Added issue to GitHub] * digital signatures
[DONE]* verify that schema validation detects if Subscription_ID and Poll_Parameters
are both set in Poll_Request
[The unmarshaller appears to create date-times that are schema valid. The regex appears to be wrong, though.]* Does unmarshalling detect dateTime values that are invalid according to the regex for
TimestampLabelType in the schema? Does it require schema validation to
detect it?
Things the XSD schema doesn't check - Add these to a Schematron schema
===============================================================================
StatusMessage
----------------
[DONE]* co-occurrence constraints between @status_type and specific <Detail> elements, expressed using XPath 2.
This expression verifies that the required Detail record exists and is the right type.
if (@status_type = 'INVALID_RESPONSE_PART')
then (taxii:Status_Detail/taxii:Detail[@name='MAX_PART_NUMBER'] castable as xs:positiveInteger)
else
if (@status_type = 'PENDING')
then (taxii:Status_Detail/taxii:Detail[@name='ESTIMATED_WAIT'] castable as xs:positiveInteger)
and (taxii:Status_Detail/taxii:Detail[@name='RESULT_ID'] castable as xs:anyURI)
and (taxii:Status_Detail/taxii:Detail[@name='WILL_PUSH'] castable as xs:boolean)
else true
[DONE]* type checking on predefined Status Detail fields
This expression verifies that if a Detail record exists, then it is the right type.
if (@status_type = 'DESTINATION_COLLECTION_ERROR'
and taxii:Status_Detail/taxii:Detail[@name='ACCEPTABLE_DESTINATION'])
then (taxii:Status_Detail/taxii:Detail[@name='ACCEPTABLE_DESTINATION'] castable as xs:anyURI)
else
if (@status_type = 'NOT_FOUND'
and taxii:Status_Detail/taxii:Detail[@name='ITEM'])
then (taxii:Status_Detail/taxii:Detail[@name='ITEM'] castable as xs:anyURI)
else
if (@status_type = 'RETRY'
and taxii:Status_Detail/taxii:Detail[@name='ESTIMATED_WAIT'])
then (taxii:Status_Detail/taxii:Detail[@name='ESTIMATED_WAIT'] castable as xs:positiveInteger)
else
if (@status_type = 'UNSUPPORTED_MESSAGE'
and taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_BINDING'])
then (taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_BINDING'] castable as xs:anyURI)
else
if (@status_type = 'UNSUPPORTED_CONTENT'
and taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_CONTENT'])
then (taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_CONTENT'] castable as xs:anyURI)
else
if (@status_type = 'UNSUPPORTED_PROTOCOL'
and taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_PROTOCOL'])
then (taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_PROTOCOL'] castable as xs:anyURI)
else
if (@status_type = 'UNSUPPORTED_QUERY'
and taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_QUERY'])
then (taxii:Status_Detail/taxii:Detail[@name='SUPPORTED_QUERY'] castable as xs:anyURI)
else true
Subscription_Management_Request
-----------------------------------
* co-occurrence constraints
[DONE]- Subscription_ID MUST be present if @action="UNSUBSCRIBE", @action="PAUSE", or @action="RESUME".
[DONE]- Subscription_Parameters is present if and only if @action="SUBSCRIBE".
Poll_Request
---------------
* co-occurrence constraint
[DONE]- Note that if both <Exclusive_Begin_Timestamp>
and <Inclusive_End_Timestamp> are present in this message, the value in <Inclusive_End_Timestamp>
MUST be greater than the value in <Exclusive_Begin_Timestamp>.
Poll_Response
-----------------
[DONE] * co-occurrence constraint: @result_id MUST be present if @more="true".
Inbox_Message and Poll_Response
--------------------------------
[DONE]* co-occurrence constraint:
Record_Count >= count(Content_Block)
(For Poll_Response, is it expected that @more=true when Record_Count > count(Content_Block)?
Should it be a rule?)
TODO
-----
[DONE - but not in the official released schema.]* Circle back and embed Schematron into XSD.
[DONE]* Convert to XSLT in build.gradle.
Additional tasks
================
[DONE]* Write utility factory methods to facilitate creating valid messages via the API.
* Generate license blurb at top of each generated file.
[DONE]* Add to Travis CI.
[DONE - I think this implies the client]* Run example code in TaxiiXml through a command-line driver to test it out.
* look at mapping extended headers and status details using
a map instead of a list - that would make it easier to find headers
or status details by name. Look at using a multimap to allow a Status Detail
or Extended Header to have a collection of list of values and avoid
marshalling problems in XML.
See http://stackoverflow.com/questions/11329388/jaxb-mapping-for-a-map
[Out of scope. This is a change to the XSD, not the Java library.]* Enhance the XSD schema by adding length checks to simple types - detect empty strings