When I look at the definition of a String type in the FIX protocol (e.g. here or here), I don't see a minimum length specified. Is it allowed to use empty strings? One online decoder seems to accept an empty string value (see tag 320), an other complains that it's invalid.
The FIX 4.4 specification states the following (emphasis in the original text):
Each message is constructed of a stream of <tag>=<value> fields with a
field delimiter between fields in the stream. Tags are of data type
TagNum. All tags must have a value specified. Optional fields without
values should simply not be specified in the FIX message. A Reject
message is the appropriate response to a tag with no value.
That strongly suggests (but does not unambiguously state) to me that the use of an empty value for a string is invalid. It is unsurprising to me that different FIX implementations might treat this edge case in different ways. So, I think the best approach is to avoid using empty values for strings.
+1 for Ciaran's and Grant's answer/comments. Just want to add something.
I generally suggest to look up things like this in the most current specification since they usually have been refined/reworded/clarified to eliminate unclear or ambiguous statements from older specs.
The answer is on the very page you link to in your question (emphasis mine, search for "Well-formed field"): https://www.fixtrading.org/standards/tagvalue-online/#field-syntax
A well-formed field has the form:
tag=value<SOH>
A field shall be considered malformed if any of the following occurs as a result of encoding:
the tag is empty
the tag delimiter is missing
the value is empty
the value contains an <SOH> character and the datatype of the field is not data or XMLdata
the datatype of the field is data and the field is not immediately preceded by its associated Length field.
Related
Reading the PostgreSQL docs, I see that you can cast a longish bit of text to xml like this:
SELECT xml '<long>long text, may span many lines</long>'
SELECT xml '...'
Curious, I found that I could do the same with JSON:
SELECT json '{"arg1":"val1", <more args spanning many lines>}'
(I couldn't find an official reference for this one. It just works!)
By contrast, this does not work:
SELECT float8 3.14159
I like this alternate syntax from a readability perspective. Now I'm looking for a reference listing which types may be specified up front like this. but I haven't found it yet.
Any pointers?
The documentation says:
A constant of an arbitrary type can be entered using any one of the following notations:
type 'string'
'string'::type
CAST ( 'string' AS type )
The string constant's text is passed to the input conversion routine for the type called type. The result is a constant of the indicated type. The explicit type cast can be omitted if there is no ambiguity as to the type the constant must be (for example, when it is assigned directly to a table column), in which case it is automatically coerced.
The form you are asking about is the first one.
So this can be used for all PostgreSQL types.
Note that the data must be specified as a string literal (in single or dollar quotes) when you use that syntax.
For example, my input text are:
You can I talk with someone
on entity I have:
#pron:aboutme = I, Me
#pron:aboutother = someone, anyone, everyone, Richard
So... I want get #pron:aboutother literal
The problem is #pron.literal returns "I" and not "someone"
How can get #pron:aboutother input literal for this case?
#sys-number is a shorthand syntax. In this case, you need to use full syntax <?entities['pron'].get(1).literal?> to get the literal of the second detected entity. It might be good to check if there are two entities of the type detected in the input before (otherwise you get arrayoutofbounds exception).
When I do app.getArgument("ARGUMENT_NAME") it returns the reference value for synonym. How do I determine the requested synonym rather than the reference value?
If you look at the JSON, this used to be available in the "result"."parameters"."name.original" field, but that seems to have changed at some point.
Now you can find it in the parameters for any of the contexts. So if you are using JavaScript and have the JSON in a variable named "body" and the argument name in a variable named "name", you can probably evaluate something like
body.result.contexts[0].parameters[`${name}.original`]
to get the value you want.
I'm learning QBasic and found an user-defined type example code in a documentation. In this example there's a string element inside an user-defined type, and that string doesn't have a length defined.
However my compiler throws the exception "Expected STRING * on..." for this example. Test-case defining the string length:
TYPE Person
name AS STRING * 4
END TYPE
DIM Matheus AS Person:
Matheus.name = "Matheus":
PRINT Matheus.name:
It logs "Math", expected "Matheus". Is there a way to allow any range for this string?
Note: I'm using QB64 compiler
No, there is not a way to use a variable-length string, even with QB64. You might look into FreeBASIC if you want this feature since it offers it.
TYPE creates a record type with the specified fields, and records have a fixed length. Look at the OPEN ... FOR RANDOM specification:
OPEN Filename$ FOR RANDOM AS #1 [LEN = recordlength%]
recordlength% is determined by getting the LEN of a TYPE variable or a FIELD statement.
If no record length is used in the OPEN statement, the default record size is 128 bytes except for the last record.
A record length cannot exceed 32767 or an error will occur!
TYPE was never intended to contain strings that are dynamically sized. This allows a developer to keep record sizes small. If you had an address book, for example, you wouldn't want people's names to be too large, else the address book wouldn't fit in memory.
QB64 didn't remove that restraint, probably to keep things compatible with older QBASIC code since the original goal was to preserve compatibility.
Say we have a URL like:
http://example.org/resources/?property=1
This will return every resource where the value of property is 1, pretty straightforward. But what if property is nullable, and we want to search for all resources with a non-null query string? I can think of a couple of ideas:
http://example.org/resources/?property
http://example.org/resources/?property=present
But the first one requires treating "" as a special value (and distinguishing it from http://example.org/resources/, where property isn't even in the URL -- which isn't necessarily straightforward in some frameworks), and the second requires declaring and documenting that present is a special value, which goes against the general principle that good API URLs ought to be obvious and unsurprising. And what if property is a free-text field that can't have any reserved words? Is there a well-accepted way of doing this?