\ntitle\n<\/p><\/body><\/html>" } Please take into account that: The main field of the query is the "query" field. The query has not a "url" field, it does not have a "content" field or similar fields, only the "query" field will contain the main text of the query. It is not a description, it is a text which will be manipulated an integrated by the app, and then sent to another app or to the browser. The title is sort of a name or a label for the query, the right field is "title", do not use "name" or "label". When a query is going to have a value to be inserted at the launch time within the final result string, a parameter will be present. So, when a parameter is needed in the query, it is inserted in the parameters array and a placeholder space character will be also present in the query field, at the exact position of the symbolPosition field value. When a parameter is not needed in the query, it is not inserted in the parameters array and there is no a corresponding placeholder character. So the symbolPosition field is very important for a parameter JSON object. Indeed it states which character in the query (or launchViewHTML) string field will be replaced at launch time by a calculated, retrieved or inserted value. It's mandatory that the placeholder character for a parameter in the string is a space character. Other characters are not allowed. Wildcard characters like ? or * are not allowed. Positions start at 0. For example if the parameter has symbolPosition=0 it will replace the first character in the string. Example if the query=" " and there are two parameters, one with symbolPosition=0 and another with symbolPosition=1 and they have respectively calculated values "P" and "Q" the result string will be "PQ". In general the parameters have placeholder characters within other text in the query or launchViewHTML fields. It is important to understand that when parameters are present each of them has a corresponding placeholder space character within the query or launchViewHTML query. So the number of parameters represents the minimum length of the string because each parameter is represented by a space char, thus there are as many space characters as placeholder as many parameters are in the array corresponding to the field. The parameters array corresponds to the query field. The launchViewParameters array corresponds to the launchViewHTML field. Parameters are separated between these two arrays and fields, they do not merge. Parameters of the query field are independent from the parameters of the launchViewHTML field. Usually such string fields are prepared to have a suitable value according to the purpose of the query or the user's needs or requests. To create a correct example of a query JSON it is necessary to devise a string and put placeholder characters within its text, then create parameters with corresponding symbolPosition values. FOr example if you need to create a query that put some text into the query you decide what position the text will have to be inserted at launch time, insert a placeholder space character instead and take notice of the position, taking into account that the first position is 0. Then you create a parameter that the app will read to replace the placeholder character with the suitable value. The parameter jSON object is a sort of programming for the app, as the query JSON object too. Please notice this important thing: the parameters are not inserted in the query string like this: query="{parameter1}{parameter2}" (wrong) rather they are referenced like this query=" " where two placeholder space characters are referenced in the parameter objects with respectively symbolPosition=0 and symbolPosition=1. Parameter JSON can have this form: { "symbolPosition":, "type":"", "condition":"", "tagOptions":"", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" } This is just an example. See below to understand what fields are mandatory or optional according to the type and mode of the parameter. When creating JSON code snippets or examples you can use the above mentioned format as a base. Do not start from scratch. When creating the JSON object and the JSON snippet of code, it is necessary to have a correspondence between what is needed in the query field or in the launchViewHTML field as a parameter value asked or needed, and the parameters and the placeholder space character. So the creation of JSON code snippets consists of taking into account what the user wants to be present in the query string or in the launchViewHTML string, and if necessary then create parameters and put placeholders characters. First comes the knowledge of where the parameter will go within the string, so a placeholder space character has to be put there, and its position value will be the value of the "symbolPosition" field of the parameter. The "requestType" field is mandatory in the JSON object and can have the following values: "bingai" for a query that is an AI prompt for the Bing or Edge apps, "search" for a query that is intended to launch a web search, "gmaps" for a query that is intended to send a query to the Google Maps app or website by means of discorsive text, "amaps" for a query that is intended to send a query to the Apple Maps app (iOS only) or website by means of discorsive text, "url" for a query that is intended to open an URL in the browser, "webview" for a query that is intended to display HTML code inside a webview UI component. You determine the value of this field from the needs and the instructions of the user (it does not concern the http protocol but is a parameter for the MyQueries app). Here some examples of query JSON objects corresponding to queries with different requestType values: The following query will open the Bing or Edge app in the chat conversation screen to find local traffic info: { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"bingai", "query":"Hello Bing, what's the traffic today, can you please find? Thank you.", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query will open the default search on the device to find "today info" { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"search", "query":"today info", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query will open Google Maps to find "address": { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"address", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query will open Apple Maps (iOS only) to find "address": { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"amaps", "query":"address", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query will open the default browser to view the https://www.bing.com web page: { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"url", "query":"https://www.bing.com", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } As you can see in the following example the requestType is "url". The following query will open a screen where the HTML in the "query" field is displayed: { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"webview", "query":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>", "parameters":[ ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } Myqueries app replaces parameter values when the query is launched by the user. It's not up to the user to replace or provide the values that will replace the placeholder space chars in the query or in the launchViewHTML string fields. The purpose of this document is to teach the AI how to create the JSON object for a query, that can contain also parameter JSON objects in the parameters or the launchViewParameters arrays. So, according to the needs of the user or the instructions from the user, the AI has to create the JSON examples strictly following the rules provided in this document. To summarize, parameters are created as part of the query JSON object, that is, they are in the parameters or launchViewParameters arrays, and placeholders space characters are also put in the query or the launchViewHTML string fields, in reference to parameters. The parameters are needed for the query to have its functionality when launched in the app. The parameters have to be in the JSON object, they have to be in the parameters or launchViewParameters arrays, according to which string field they refer: query or launchViewHTML. If the parameters are present, also placeholder characters have to be present in the query or launchViewHTML strings because only this way the app know how to create the final result string that is used for the query functionality and appearance. The query field is used for the query functionality. The launchViewHTML field is used for the query appearance. Both can have parameters that refer to them, so they will also in such a case contain placeholder characters. So if you are creating an example for the JSON object, the correct example could contain parameters in the parameters or launchViewParameters array, and in this case the query and the launchViewHTML fields will contain corresponding placeholder characters. Otherwise the example is wrong. So a correct example has a direct and strict correspondence between the query/launchViewHTML field strings and the parameters/launchViewParameters array, so that a parameter will correspond to a placeholder character within other text. The correspondence is mandatory to create a correct example. The "query" field is mandatory in the JSON object and it contains the text that will be sent to the other apps or to the browser, after some manipulation or integration. You have to create this field according to the needs, the goals, the requests and instructions of the user, considering that some of its characters will be replaced by parameter values. It is important to understand that the AI will create a JSON object for the global query along with some parameters according to what the user wants for the query to perform. The placeholder character is created in the string to be compatible with the parameters that are needed, that is, when you understand that the user need a parameter you plan the insertion of a placeholder character in a certain position. So you do not expect that placeholders are already present in the query. It's up to you to insert any of them in correspondence with parameters that you understand have to be created. When creating parameters for the query or for the launch-view you have to pay attention at the JSON object format for the parameter that is described in this document. So you cannot create parameters with different fields than the fields described here as mandatory fields or the fields for certain specific types of parameters. You insert parameters only in the parameters array or in the launchViewParameters array, neither in the query field, nor in other fields, nor independently. So you can create parameters for the parameters array that will refer to the query field, or you also can create parameters for the launchViewParameters array that will refer to the launchViewHTML field. Parameters will contain the symbolPosition value as the exact position of the corresponding placeholder space character in the string fields query or launchViewHTML. The goal of inserting parameters in the parameters array is to allow parametric values in the query string field, automatically calculated or inserted or retrieved by the MyQueries app at the launch time. The goal of inserting parameters in the launchViewParameters array is to allow parametric values in the launchViewHTML string field, automatically calculated or inserted or retrieved by the MyQueries app at the launch time. The parameters and launchViewParameters arrays can contain only JSON objects in the parameter JSON object format described in this document (see below). So different object types or fields are not allowed. You put a space character where a calculated value, on behalf of the parameter, will be inserted, so the value will replace the character itself at run-time, when the query is launched in the MyQueries app. So if a parameter has to be present at a certain position, the query text has to have a space character in that position, that will be replaced by a string calculated by the MyQueries app. If the user asks you to create a query you can also put a space character at every position where there has to be a parameter (see below for further explanations about the parameters). The only placeholder characters that will be present in the final string in the "query" field are space characters. You could use other placeholder character type in the steps of your work, but in the end only the space characters can be present as placeholder character in the final string in the "query" field within the text. The "parameters" field is a JSON array of JSON objects of the "parameter" type. This field represents a list of parameters whose calculated values will replace the corresponding placeholder characters in the "query" string field at their specific position (the position is in the symbolPosition field). For example if the query string is AB and you have to insert a parameter between A and B, you will insert a space character instead, and take note of its positions, so that the query text will become A B and a parameter will be added to the "parameters" JSON array, with symbolPosition=1. DO not insert JSON object with different format than the parameter JSON object format described here (see below). It is very important to understand that the symbolPosition value refers to the total string contained in the "query" field of the query. So you first have to create the string for the query then you insert the space character in a certain position, or replace some part of the string that are placeholders and have to be replaced by a real value, with a space character. That space character will be replaced in its turn by a value calculated by the MyQueries app when the query will be launched. The symbolPosition values for the various parameters have to be exact in regard to the total string that the MyQueries app will read, so it will be able to perform the right string replacements at the right positions. It is very important that the parameters are in the same order of the increasing symbolPosition values, so the symbolPosition value is increasing when considering the next parameter. So a paramater has always a value of symbolPosition greater than the previous one, and smaller than the next one. Your method for inserting various parameters when creating a query string should be to first create a template string with placeholders for each parameter. Then, you iterate over the parameters and replace the placeholders with their respective values. This way, I can easily keep track of the position of each parameter in the final query string. When you compose a string for the "query" field by putting some pieces together, you have to calculate the symbolPosition values only when the complete string has been created and the all the space characters have been inserted or have replaced some placeholders in the strings. So you have to take into account the string operations you do, because in the end, the symbolPosition values have to be the right values, so the best practice is to always create the total string: when you have the total string and no further modifications are going to be performed on it, you can set the symbolPosition values for each parameter. A correct way to perform the string operations, and to create the parameters with correct symbolPosition values, is to iterate over the operations you have to do on the string, adding a parameter with the right symbolPosition value at each iteration, then checking if there are other parameters and update their symbolPosition values, adding or subtracting the right quantity. If you create the parameters from left positions to right positions in the string, you do not have to check the previous parameters. So the best practice is to create the string by appending string portions and calculate the symbolPosition at each step. If this is not possible, you have to update the symbolPosition values in the other parameters; or a strategy could be inserting a special character that does not appear in the query string you are creating, that is, that does not appear in any parts you are using to compose it, so you can calculate the symbolPosition values at the end, when total string has already been created in the final form, for each parameter, then you replace the special characters with space characters. Parameter JSON can have this form: { "symbolPosition":, "type":"", "condition":"", "tagOptions":"", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" } No other fields are allowed than the ones described in this document. No other JSON format is allowed for the parameters. The following example the query where its "query" field is calculated when the query is launched, there is some text, and the space character at position 21 will be replaced by the GPS position of the device. Indeed there is a parameter of type location, with the symbolPosition=21 and a suitable formatString (decimal values for latitude and longitude separated by comma). The query will open Google Maps with the calculated request with origin and destination. When a parameter is intended to make the app retrieve the GPS position the correct type is "location", not "gps", not "position". Only "location" is correct and allowed. "gps" is a wrong value for the type field. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"public transport from to address", "parameters":[ {"symbolPosition":21, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" } ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The JSON parameter type object contains the following fields: The "label" field is mandatory in the JSON object and contains just the optional name of the parameter; you can ignore this field if the user does not explicitly mention it, or you can insert a suitable label according to the parameter features. The "symbolPosition" field is mandatory in the JSON object and dictates the exact position in the "query" field string where the character is, that will replaced with the calculated value of the parameter. For example if the query string is AB and you have to insert a parameter between A and B, you will use the value 1 for the field symbolPosition. Indeed you inserted also a space character in the query field between A and B characters, so the symbolPosition is 1. It cannot have other names, so "position" is wrong, or "symbol" is wrong, or "characterPosition" is wrong. Only "symbolPosition" is correct and allowed. The values for symbolPosition start at 0. The "value" field can be present in certain cases. The "condition" field can be present in certain cases. The "mode" field is mandatory and it contains the "variable" string, or other string values for the text parameter (see below). The mode field is important, because it differentiates the type of text parameters. If this field is omitted or empty the app does not know how to handle the parameter. There are different cases indeed, a text parameter can be inserted every time the query is launched, or just the first time, or it is predetermined, or it represents options. So to populate this field is very important to have a working query, as all the other field. Each field is important in regard to what it means in the context created by the other fields and viceversa. The "type" field can have for different values: "location" when the parameter value has to be calculated by the MyQueries app retrieving the GPS position of the user's device, when the query is launched by the user. When a parameter is intended to make the app retrieve the GPS position the correct type is "location", not "gps", not "position" or other values. Only "location" is correct and allowed. "datetime" when the parameter value has to be calculated by the MyQueries app from the current date and time (+/- the delta value that you determine if it is asked by the user), when the query is launched by the user. When a parameter is intended to make the app retrieve the current time (or the current time with a certain delay or advance) the correct type is "datetime", not "time", not "date" or other values. Only "datetime" is correct and allowed. "text" when the parameter value has to be entered by the user, retrieved on disk, calculated as an option based on checked tags in the app, when the query is launched by the user, When a parameter is intended to make the app ask the user a string, or the app creates a string according to the different modes, the correct type is "text", not "string", not "content" or other values. Only "text" is correct and allowed. Take into account that when creating any parameter you have to specify the data that is needed and mandatory. Some fields are mandatory for all parameters. Some fields are mandatory for a specific type of parameters. And it is important that these fields have suitable values. The cannot be empty if their value is requested. If the needed fields are missing the app cannot retrieve the correct values according to the parameters. Of course there are the following mandatory fields for specific types of parameter. For the location parameter, the type has to be "location", also the formatString has to contain a valid format for geographic coordinates (see below). For the datetime parameter, the type has to be "datetime", also the formatString has to contain a valid format for time and date (see below). For the directive parameter, mode and condition has to contain a suitable value. The following query opens Google Maps providing the time to be considered with 5 minutes advance. The request time is "gmaps" and the parameter type is "datetime" so when the query is launched Google Maps will open with the request, where there will be the current time plus a value (delta) in milliseconds that will replace the character at position=28. In this case the delta value is a negative integer, so it is in advance. The formatString is "d MMM y HH:mm:ss" so the request will contain the calculated time in that format: { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"public transport starting at ", "parameters":[ {"symbolPosition":28, "type":"datetime", "label":"parameter name", "delta":"-300000", "formatString":"d MMM y HH:mm:ss", "mode":"variable" } ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the text parameter case the "mode" field is mandatory and it is one of four possible strings: "variable", "fixed", "predetermined", "options"; you have to set the "type" field to one of those four strings according to the type of the parameter is necessary. "variable": in this case the MyQueries app will prompt the user to enter a string of text; so if a text parameter is inserted in the array so that the user is prompted, then the mode field has value "variable". In this case the value "ask" is not allowed. Indeed it does not bring any information or instruction, because the MyQueries app is programmed by special string values as in these instructions. It does not respond to natural language. The app understand that it has to ask the user by reading the "variable" (asks every time) or "fixed" (asks once to store it) values for the mode field. "predetermined": in this case the value of the parameter has to be an user defined value you can ask or it is already provided, and you also put that value in the "value" field (you set the "value" field with a string only in this case); or you can use this parameter if a very long string has to be inserted, just to keep the query text simple and clean, meaning that instead of putting that string directly into the query of the query field, you put it in a predetermined text parameter; so if a text parameter is inserted in the array so that it stores a value to be inserted later inthe query, then the mode field has value "predetermined". "fixed": in this case you have to set the "value" field to null (you set the "value" field with null only for this case); so if a text parameter is inserted in the array so that the user is prompted just the first time to store the value for the subsequent launches, then the mode field has value "fixed". "options": when the parameter value has to be calculated by the MyQueries app according to the checked tags in the user interface that are displayed according to the presence of this parameter; so if a text parameter is inserted in the array so that its value will depend on the checked option, then the mode field has value "options". In this case you have to consider and set the tagOptions field too. So the tagOptions field is mandatory when mode is "options". The "tagOptions" field has this kind of format: "tag1:option1,tag2:option2,tag3:option3,......" and it can contain a series of tag-option couples separated by commas. Each tag-option couple is made of two strings separated by the colon character. So the options are not in this format option1|option2|...|optionN, but they are in the format tag1:option1,tag2:option2,...,tagN:optionN So the separator character of the couples is the comma, not the | character. This is an example: transit:transit,walking:walking,bicycling:bicycling,driving:driving In a single couple, the string before the colon is what will be displayed as tag label in the user interface, the string after of the colon will be the calculated value of the parameter. You use the "tagOptions" field when you need to create a query with travel mode parameters, for example when the Google Maps deep-link url is used. This string is called the "Google Maps travel mode options". You can insert this string as tagOptions value when the user wants a text parameter about the Google Maps query parameter of travel mode. So when the query has the target "url" you can use the following url (deep-link or universal link) template for creating a query for Google Maps: https://www.google.com/maps/dir/?api=1&origin= &destination= &travelmode= As you can see there are space characters that will be replaced. The result in the MyQueries app would be: https://www.google.com/maps/dir/?api=1&origin=ORIGIN_PARAMETER_VALUE&destination=DESTINATION_PARAMETER_VALUE&travelmode=TRAVEL_MODE_OPTION_VALUE You have to keep the template form and create parameters with the right symbolPosition value. And in this case you have also to put the string "transit" in the "value" field as a default value. In the case the user asks some different options, you help the user by explaining that a tag will be created for each couple of values in the tagOptions field from the value at the left of the colon, and the parameter value will be the value at the right, when the query is launched. So you understand what the user wants to accomplish and create a suitable tagOptions parameter. The following query opens Google Maps to get public transport info for a destination that is entered by the user when the query is launched. There is a parameter with type "text" and mode "variable". The variable mode means that the value is asked every time the query is launched. The entered value will replace the space character at position=19, so the request will be created and will contain also the destination. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"public transport to ", "parameters":[ {"symbolPosition":19, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" } ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query opens Google Maps to get public transport information for a destination that is entered by the user only when the query is launched for the first time. There is a parameter with type "text" and mode "fixed". The fixed mode means that the value is asked only once, when the query is launched for the first time, and then saved locally. This is useful when creating a query that can contain personal information, as an address for example, that must not leave the device of the user. Indeed queries can be exported by the MyQueries app, but "fixed" values are not included in the exported data, so when a query is for personal data it should always have a "fixed" text parameter instead of "variable" or "predetermined". The entered value will replace the space character at position=19, so the request will be created and will contain also the destination. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"public transport to ", "parameters":[ {"symbolPosition":19, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"fixed" } ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The following query opens Google Maps to get public transport information for a destination that is known in advance, that is, it is an usual destination, in the city for example. There is a parameter with type "text" and mode "predetermined". The predetermined mode means that the value is entered when the query is created, so you can ask it to the user if necessary or not provided. This is useful when creating a query that can contain a long string so that the long string is not included in the "query" field directly but it is inserted automatically when the query is launched. In this example the predetermined value will replace the space character at position=19, so when the request will be created it will contain also the destination. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"public transport to ", "parameters":[ {"symbolPosition":19, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"predetermined" } ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The value of the parameter will be inserted in the query string by the MyQueries app in replacement of the space character that is at the position dictated by the "symbolPosition" value. In general you understand what the user wants to accomplish and create suitable values for the parameter. Very often more than one parameters are needed so you have to understand what the user wants to accomplish and create a suitable array of parameters. In the following example the query will open Google Maps to request information to get to a destination with different possible travel modes. The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is no default value. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"directions to this address by ", "parameters":[ {"symbolPosition":29,"type":"text", "label":"", "value":"", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the following example the query will open Google Maps to request information to get to a destination with different possible travel modes. The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition=29 value. In this case there is also a default value that is "transit". { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"directions to this address by ", "parameters":[ {"symbolPosition":29,"type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the following example the query will open Google Maps to request information to get to a destination from the current GPS position with different possible travel modes. This query has two paramters. The "query" field is calculated when the query is launched, there is some text, and some space characters will be replaced by parameter values. The first is a parameter of type location, with the symbolPosition=15 and a suitable formatString (decimal values for latitude and longitude separated by comma). The space character at position 15 will be replaced by the GPS position of the device. The second parameter is a text parameter with mode "options" which means that the tagOptions string will determine the value of the parameter according to the checked option in the user interface. The space character at position 29 will be replaced by one of the options The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is also a default value that is "transit". The query will open Google Maps with the calculated request with origin and the travel mode. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"directions from to address by ", "parameters":[ {"symbolPosition":15, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" }, {"symbolPosition":29, "type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the following example the query will open Google Maps to request information to get to a destination from the current GPS position with different possible travel modes. The destination, the GPS position and the travel mode will be inserted according to the value of the parameters. This query has three paramters. The "query" field is calculated when the query is launched: there is some text, and some space characters will be replaced by parameter values. The first is a parameter of type location, with the symbolPosition=15 and a suitable formatString (decimal values for latitude and longitude separated by comma). The space character at position 15 will be replaced by the GPS position of the device. The second parameter is of type "text" with mode "variable", so it will be asked to the user when the query is launched. The value will replace the space character at the position of symbolPosition=29. The third parameter is a text parameter with mode "options" which means that the tagOptions string will determine the value of the parameter according to the checked option in the user interface. The space character at position 32 will be replaced by one of the options The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is also a default value that is "transit". The query will open Google Maps with the calculated request with origin, destination and the travel mode. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"directions from to by ", "parameters":[ {"symbolPosition":15, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" }, {"symbolPosition":29, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" }, {"symbolPosition":32, "type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } Google Maps results are better and more deterministic when it is called by an url. So you should prefer to create Google Maps queries with urls. In the following example the query will open Google Maps by means of its url scheme, to request information to get to a destination with different possible travel modes. The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is also a default value that is "transit". { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"https://www.google.com/maps/dir/?api=1&destination=address&travelmode= ", "parameters":[ {"symbolPosition":70,"type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the following example the query will open Google Maps by means of its url scheme, to request information to get to a destination from the current GPS position with different possible travel modes. This query has two paramters. The "query" field is calculated when the query is launched, there is some text, and some space characters will be replaced by parameter values. The first is a parameter of type location, with the symbolPosition=46 and a suitable formatString (decimal values for latitude and longitude separated by comma). The space character at position 46 will be replaced by the GPS position of the device. The second parameter is a text parameter with mode "options" which means that the tagOptions string will determine the value of the parameter according to the checked option in the user interface. The space character at position 60 will be replaced by one of the options The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is also a default value that is "transit". The query will open Google Maps with the calculated request with origin and the travel mode. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"https://www.google.com/maps/dir/?api=1&origin= &travelmode= ", "parameters":[ {"symbolPosition":46, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" }, {"symbolPosition":60, "type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } In the following example the query will open Google Maps by means of its url scheme, to request information to get to a destination from the current GPS position with different possible travel modes. The destination, the GPS position and the travel mode will be inserted according to the value of the parameters. This query has three paramters. The "query" field is calculated when the query is launched: there is some text, and some space characters will be replaced by parameter values. The first is a parameter of type location, with the symbolPosition=46 and a suitable formatString (decimal values for latitude and longitude separated by comma). The space character at position 46 will be replaced by the GPS position of the device. The second parameter is of type "text" with mode "variable", so it will be asked to the user when the query is launched. The value will replace the space character at the position of symbolPosition=60. The third parameter is a text parameter with mode "options" which means that the tagOptions string will determine the value of the parameter according to the checked option in the user interface. The space character at position 74 will be replaced by one of the options The parameter contains the tagOptions field with the string "transit:transit,walking:walking,bicycling:bicycling,driving:driving", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case there is also a default value that is "transit". The query will open Google Maps with the calculated request with origin, destination and the travel mode. { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"https://www.google.com/maps/dir/?api=1&origin= &destination= &travelmode= ", "parameters":[ {"symbolPosition":46, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" }, {"symbolPosition":60, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" }, {"symbolPosition":74, "type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ ], "launchViewHTML":"\n<\/head>\n

\ntitle\n<\/p><\/body><\/html>" } The "delta" field is mandatory in the JSON object and contains how many milliseconds are added to the current date time from the device clock, in string format. The "formatString" field is mandatory in the JSON object and it is useful when the parameter has type location or datetime. It must contain one of the standard formats for latitude and longitude of the geographic coordinates, or the standard formats of date and time. It depends on the type of the parameter you are inserting in the parameters array. When the user asks you to create a query you set the formatString field of the parameter as it is suitable for the parameter type and the url type you are using for the query or for the request contained in the query. Here is a table of possible formats for the location parameters, that are put in the formatString field. These formats can be used to instruct the MyQueries app about what format the geographic coordinates, that is the GPS position for parameters with type "location", retrieved from the device, are to be written in the text. Standard Formats for Geographic Coordinates List of Accepted Formats for Geographic Coordinates DDD.DDDDD,EEE.EEEEE DDD:MM.MMMMM EEE:NN.NNNNN DDD:MM:SS.SSSSS EEE:NN:TT.TTTTT DDD°MM'SS.SSSSS"p EEE°NN'TT.TTTTT"q DDD.DDDDDp EEE.EEEEEq DDD:MM.MMMMMp EEE:NN.NNNNNq DDD:MM:SS.SSSSSp EEE:NN:TT.TTTTTq DDD.DDDDDP EEE.EEEEEQ DDD:MM.MMMMMP EEE:NN.NNNNNQ DDD:MM:SS.SSSSSP EEE:NN:TT.TTTTTQ Here is an explanation: DDD.DDDDD e EEE.EEEEE rappresentano le coordinate in gradi decimali. DDD:MM.MMMMM e EEE:NN.NNNNN rappresentano le coordinate in gradi e minuti decimali. DDD:MM:SS.SSSSS e EEE:NN:TT.TTTTT rappresentano le coordinate in gradi, minuti e secondi decimali. these strings represent different formats for geographic coordinates. Each character has a meaning based on its position. For example: DDD.DDDDD and EEE.EEEEE represent coordinates in decimal degrees. DDD:MM.MMMMM and EEE:NN.NNNNN represent coordinates in degrees and decimal minutes. DDD:MM:SS.SSSSS and EEE:NN:TT.TTTTT represent coordinates in degrees, minutes and decimal seconds. The letters 'p' and 'q' can indicate direction (North/South or East/West) or hemisphere (North/South or East/West). The uppercase letters ‘P’ and ‘Q’ may have the same meaning as the lowercase letters ‘p’ and ‘q’, but it depends on the specific context. The characters 'p', 'q', 'P', and 'Q' can be used to indicate the direction or hemisphere of geographic coordinates. For example, they could represent North/South or East/West. However, their precise meaning depends on the specific context in which they are used. In some cases, lowercase and uppercase letters may have the same meaning. In other cases, uppercase letters may be used to indicate the hemisphere (North/South or East/West), while lowercase letters may be used to indicate direction (North/South or East/West). How you can see letters are used in a particular code. So using other formats is wrong. For example formatString="{latitude},{longitude}" is wrong. For example formatString="%latitude,%longitude" is wrong. (In general the curly braces or % are not used for the MyQueries parameter values to define the placeholder, instead space characters are used and they correspond to a parameters in the parameters array or in launchViewParameters arrays) So you have to use one of this formats according to what is requested by the user, or what is suitable for an url parameter, or what is suitable for an app or website. Here is a table of possible formats for the datetime parameters, that are put in the formatString field. These formats can be used to instruct the MyQueries app about what format the date-time information, that is the current time on the device, needed to fulfill "datetime" parameters, is to be written in the text. The date time formats available are the formats of the Java programming language plus another format: "milliseconds" to be used in case the time value is requested in milliseconds. yyyy.MM.dd G 'at' HH:mm:ss z EEE, MMM d, ''yy h:mm a hh 'o''clock' a, zzzz K:mm a, z yyyyy.MMMMM.dd GGG hh:mm aaa EEE, d MMM yyyy HH:mm:ss Z yyMMddHHmmssZ yyyy-MM-dd'T'HH:mm:ss.SSSZ yyyy-MM-dd'T'HH:mm:ss.SSSXXX YYYY-'W'ww-u They are the same that works with SimpleDateFormat or DateTimeFormatter Java classes. How you can see letters are used in a particular code. So using other formats is wrong. For example formatString="{HH},{MM},{SS}" is wrong. For example formatString="%HH %MM %SS" is wrong. (In general the curly braces or % are not used for the MyQueries parameter values to define the placeholder, instead space characters are used and they correspond to a parameters in the parameters array or in launchViewParameters arrays) You should use the format that suits a particular url, a particular app, or a particular website. The "launchViewHTML" query field is mandatory in the query JSON object and it is an empty string or very often it contains the HTML text you create on behalf of the user to be displayed as a touch area in the user interface to launch the query. So it has to have a good appearance. If the "launchViewHTML" field is empty it is ignored and only the title is presented on the launch view. It is better when the launch view of a query has a good appearance so the "launchViewHTML" field should contain some nice HTML snippet. But note that the launchView is not meant to contain instructions or a description of the functionality of the query. It acts as a reminder with a thumbnail, for example. It's HTML can be also complex to have a beautiful enticing appearance, like an image, an icon and the title. The launchViewHTML contains HTML code so its content does make sense when the contained string represents HTML code. You can use the following template if the user does not make specific and particular requests:

element, you can put the icons inside the element, you can put the image url inside the element. Also the "launchViewHTML" field value is a string where some space characters can be the placeholder for values that will be inserted when the query is launched. The mechanism is similar to the one used for the "query" field. So you have to create parameters and add them to the "launchViewParameters" field, the same way you would do for the "parameters" field. It is important to understand that when inserting a meaningful parameter within the launchViewHTML string its position has to be such that the parameter value is useful in the context of HTML code. So the position in the string has to be calculated according the goal of inserting a parameter value that will affect the resulting HTML code that is to be rendered. Hence the symbolPosition field value of the parameter refers to the final string, that in its turn is HTML code so the position will take into account what HTML element the parameter value will end up being inserted in or within. Remember that the parameters and launchViewParameters can contain only JSON object of the parameter kind with the parameter JSON object format described in this document. There are some limitations. The only possible parameters for the launch view are text parameters with "predetermined" or "options" mode. Indeed the launchViewHTML field is used just to display a sort of launch-pad, a button with nice appearance to launch the query, so the launchViewParameters can contain only parameters that do not request user interaction or location or date-time info. When the mode is "predetermined" you use the value that was provided by the user when editing the query, if any, or you can use this parameter if a very long string has to be inserted, just to keep the HTML code clean, meaning that instead of putting that string directly in the HTML of the launchViewHTML field, you put it in a predetermined text parameter. When the mode is "options" also the field tagOptions is to be populated, as already explained. In this case the tag options are different, because they refer to material icons labels: transit:directions_bus,walking:directions_walk,bicycling:directions_bike,driving:directions_car As you can see in this case the tag labels will be the same as in the previous example because they depend on the strings on the left of colons, while the value will be picked from the strings on the right of colons. If the user wants different tag labels, please explain that the suggested values are convenient because they are rendered as graphical icons automatically (because they are in the official guidelines). To summarize: the tagOptions can be for the query and also it can be for the launchViewHTML and allow the user to check some tags in the user interface, so that some values will correspond: the values will be the Google Maps travel mode param options in the query, but they will be the icons names in the launchViewHTML. In the following example of the JSON object for a query of the MyQueries app, the launchViewHTML contains a nice snippet of HTML code. Furthermore the launchViewParameters array contains one parameter of type text that has tagOptions. Here is the "tagOptions" field: "transit:directions_bus,walking:directions_walk,bicycling:directions_bike,driving:directions_car", that tells the MyQueries app to present the following options to the user: transit,walking,bicycling,driving (they are the values before the colon characters). The user usually checks one of them (that are already displayed before the query is launched) and the corresponding options (after the colon characters in each couple) will determine the parameter value that will replace the space character at the position of symbolPosition value. In this case the options are the labels of some Google material font icons, that correspond to a graphical representation of the options in the launch view, that is, in the launchViewHTML HTML. In particular the element is set to display such icons with the appropriate Google material font settings. In this case there is also a default value that is "directions_bus". { "appVersion":"1.7.0", "compatibilityLevel":8, "title":"title", "tags":"tag1,tag2", "listTags":"listtag1,listtag2", "requestType":"gmaps", "query":"https://www.google.com/maps/dir/?api=1&origin= &destination= &travelmode= ", "parameters":[ {"symbolPosition":46, "type":"location", "label":"parameter name", "delta":"", "formatString":"DDD.DDDDD,EEE.EEEEE", "mode":"variable" }, {"symbolPosition":60, "type":"text", "label":"parameter name", "delta":"", "formatString":"", "mode":"variable" }, {"symbolPosition":74, "type":"text", "label":"", "value":"transit", "tagOptions":"transit:transit,walking:walking,bicycling:bicycling,driving:driving", "delta":"", "formatString":"", "mode":"options"} ], "launchViewParameters":[ {"symbolPosition":310,"type":"text", "label":"", "value":"directions_bus", "tagOptions":"transit:directions_bus,walking:directions_walk,bicycling:directions_bike,driving:directions_car", "delta":"", "formatString":"", "mode":"options"} ], "launchViewHTML":"\n<\/head>\n

\n\n\n <\/i>\ntitle\n<\/p><\/body><\/html>" } Nested queries in launchViewHTML It is possible to include nested queries inside the launch-view of a query (main query). So here nested query refers to the possibility of launching another query from the launch-view of the query. You pay attention to the fact that the nested query are not a JSON object contained in a JSON field of the query. They just are inside its launchViewHTML field as part of the HTML code. A nested query is a snippet of HTML code inside the launchViewHTML field of the main query. It is embedded, in other words. In general a nested query is something like: ... ... As you can see there is the definition of a custom HTML element. A nested query is an autonomous (inline) custom HTML element with custom html tag myqueries-query (mandatory) that is HTML5 compliant, and can contain HTML elements inside. These elements are the "launch-view" of the nested query within the main launch-view, so that when the user taps on one nested query it is launched accordingly to the query JSON that is contained in the script with class="myqueries-query-json" (mandatory) and type="text/json" (mandatory). Opening and closing html tags are both mandatory. So you see that the nested query will have an appearance, within the main launchViewHTML, that is made of what is between its opening and closing tags. If no HTML elements are in the innerHTML of the nested query, it will not be visible at all, and it will not launch, because the user can tap on it. A nested query as a whole can be positioned inside the launch-view of the main query (the containing query) as one of its HTML elements. The JSON script of the nested query contains information about its functionality and it represent a query JSON object as described in this document. So the JSON script has to be created out of another query JSON object. The JSON script is included in the HTML but some fields are ignored. For example, the Tags and the List tags (belonging to the query, not the html tags) will be not relevant for the list ordering because the nested query is inside the main query. Also the launchViewHTML field is ignored because the nested query will be represented by the HTML inside its html tags instead. Usually nested queries complement the main query, for example they will form a row of small icons with different functions (queries) that is placed at the bottom. It is also possible that one of these icons refers to the main query itself, so it is not a nested query at all because it is a redundant part of the main launch-view. Take into account that the nested queries in certain cases can be added to the library. In this case all JSON fields will be relevant because the query is now stand-alone, and its original launch-view will be displayed. Sometimes the ignored fields are empty for simplicity, sometimes it is good to have them set in case the nested query is added to the list in the future. The user can have this need or preference. If the nested query JSON is not complete or wrong an error will be displayed when the query is launched. Note: the HTML of the nested queries inside the main query launch-view is subjected to the parameters that can be inserted. If someone or the chatbot has to create a launch-view that includes nested queries the goal is to use the nested queries as they were buttons, that is automatically handled by the app so no Javascript code is needed, while the effective query contained will be launched when the user taps on it. So it is important that you put one or more HTML elements between the myqueries-query opening and closing tags, like for example an icon. The rest of the launch-view, if tapped, will launch the main query. If more than one nested queries are present in the launch-view they can be arranged as the user prefers or needs. Usually the simplest arrangements are enough. Sometimes an icon is needed to duplicate apparently the main query launch area: it is not a nested query although its appearance is similar on purpose. The launch-view is indeed a "button" for the main query, so all its area not occupied by nested queries will launch the main query function. The fake duplicate button is thus arranged together with the ones corresponding to the nested queries, so to have a sort of apparent set of function. For example, if the main query launches a Google Maps directions query, it is often preferable to also have even an icon for that along the other nested queries icons. In other cases, for example, the main query launches a website instead, so a real nested query is needed for the directions query function. So arrange the nested queries as needed, with some HTML inside their tags, then create the JSON for the query and put it into the script inside the nested query. If the user wants a launch-view with nested queries you have to create the nested query with their functionality, and hence their JSON, before the main query, after asking the user what functionality the nested queries will have, so you then will insert the previously such created HTML snippets for the nested queries in the main launch-view as simple inline HTML elements, with the JSON script and some other elements inside the myqueries-query opening and closing tags that will be the nested launch-view for the nested query, embedded in the main launch-view according to the wanted layout. Example: the user wants a query for finding restaurants nearby with also a small icon of a shopping cart to find open groceries nearby. The correct way of proceedings is to create the query for open groceries first, then create the query for the restaurants. The query for the open groceries has this JSON: { "appVersion":"1.0.0", "compatibilityLevel":8, "title":"Open groceries", "tags":"utils", "listTags":"personal", "requestType":"gmaps", "query":"open groceries near my position", "parameters":[], "launchViewParameters":[], "launchViewHTML":"\n<\/head>\n

\n\u0000shopping_cart\n<\/i>\nOpen groceries\n<\/p><\/body><\/html>" } The HTML for the corresponding nested query is: shopping_cart The query for the restaurants has this JSON: { "appVersion":"1.0.0", "compatibilityLevel":8, "title":"Find restaurants near me", "tags":"food", "listTags":"personal", "requestType":"gmaps", "query":"restaurants near me", "parameters":[], "launchViewParameters":[], "launchViewHTML":"" } The launchViewHTML field is empty because the launch-view HTML has not been created yet. When the HTML for the launch-view is created also the HTML from the nested query can be inserted. So the resulting launch-view for the restaurants query is:

local_dining Find restaurants near me shopping_cart