# \[Bug?\] Document Tag Reading Values with Numeric Keys or Spaces **URL:** \ **Category:** Ignition\ **Created:** [November 23, 2020, 8:40am UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880 "2020-11-23T08:40:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [November 23, 2020, 8:40am UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880/1 "2020-11-23T08:40:08Z")
Hi, I’m trying to refactor some code to take advantage of the deep reading of objects in 8.1, as stated here: [docs](https://docs.inductiveautomation.com/display/DOC81/Tag+Paths#TagPaths-DocumentTypeTags) I have found that this syntax only works for documents that have alpha numeric keys. See example below: The memory tag ([Development]DocTag) has a value as follows: ```auto "value": { "data": { "alphaNumeric1": "alpha numeric 1", "1": "this key is a number", "has spaces": "this key has spaces" } } ``` I can only read the keys that are alphanumeric. Any keys that are a number or contain spaces result in a malformed path exception. Results (with. [key.deepKey] notation: ```auto print system.tag.readBlocking(["[Development]DocTag['data']"]) >>> [[{alphaNumeric1=alpha numeric 1, 1=this key is a number, has spaces=this key has spaces}, Good, Mon Nov 23 10:19:40 CAT 2020 (1606119580207)]] print system.tag.readBlocking(["[Development]DocTag['data.alphaNumeric1']"]) >>> [[alpha numeric 1, Good, Mon Nov 23 10:19:40 CAT 2020 (1606119580207)]] print system.tag.readBlocking(["[Development]DocTag['data.1']"]) >>> [[null, Error_Exception("Malformed path: data.1"), Mon Nov 23 10:31:32 CAT 2020 (1606120292149)]] print system.tag.readBlocking(["[Development]DocTag['data.has spaces']"]) >>> [[null, Error_Exception("Malformed path: data.has spaces"), Mon Nov 23 10:31:32 CAT 2020 (1606120292153)]] ``` Same with [‘key’][‘deepkey’] notation: ```auto print system.tag.readBlocking(["[Development]DocTag['data']"]) >>> [[{alphaNumeric1=alpha numeric 1, 1=this key is a number, has spaces=this key has spaces}, Good, Mon Nov 23 10:19:40 CAT 2020 (1606119580207)]] print system.tag.readBlocking(["[Development]DocTag['data']['alphaNumeric1']"]) >>> [[null, Error_Exception("Malformed path: data']['alphaNumeric1"), Mon Nov 23 10:36:42 CAT 2020 (1606120602222)]] print system.tag.readBlocking(["[Development]DocTag['data']['1']"]) >>> [[null, Error_Exception("Malformed path: data']['1"), Mon Nov 23 10:36:42 CAT 2020 (1606120602226)]] print system.tag.readBlocking(["[Development]DocTag['data']['has spaces']"]) >>> [[null, Error_Exception("Malformed path: data']['has spaces"), Mon Nov 23 10:36:42 CAT 2020 (1606120602229)]] ``` Is this a bug or am I doing something wrong? Regards, Deon ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 23, 2020, 12:11pm UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880/2 "2020-11-23T12:11:29Z")
Seems pretty normal to me, from a language perspective. While not a programming language per-se, syntax like that is generally implemented with parsers for programming languages. Which means you should only expect keys that would be acceptable identifiers in a programming language to work. Whether that is IA’s _intent_ or not. It is tempting to use Ignition’s tolerance for any old string in the names of various items in its platform, but your life will be much simpler if you treat all internal names as if they are java/jython/python variable names, and follow those rules. Consider including this in your refactoring. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 23, 2020, 3:57pm UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880/3 "2020-11-23T15:57:10Z")
As a workaround, you could read the entire tag, and then do the data extraction ‘manually’ - I’m pretty confident something like this would work (you will have to use the `[0]` to retrieve the first element out of the result list - not the prettiest syntax ever: ```auto print system.tag.readBlocking(["[Development]DocTag"])[0]['data']['1'] ``` ---
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [November 23, 2020, 4:35pm UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880/4 "2020-11-23T16:35:07Z")
That is exactly what I’ve been doing up to know. It just feels unnecessarily heavy to read the whole document, which is a huge database cache, only to extract a single value. The keys in the document tag is actually the database primary key. I can do something funny, like make the key id1234, where 1234 is the PK. Probably best to avoid non complaint keys to start with, as Phil said. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 23, 2020, 4:57pm UTC](https://forum.inductiveautomation.com/t/bug-document-tag-reading-values-with-numeric-keys-or-spaces/40880/5 "2020-11-23T16:57:37Z")
Well, I can say that reading the whole document to extract the specified key is very likely also what we’re doing - I’d have to dive into the code to confirm, but I don’t think there’s any mechanism to deliver a true partial value like that.