Feature Request: Add a type resolver in a similar way to the namespace resolver.

[Parakleta]

Let me start by saying this library has been a lifesaver for us, so thank you.

We are using this to run the XPath expressions from an XSD document to pre-validate a user generated XML document before it is submitted through a webpage. When full validation is done with the schema document type annotations are added which are then used by the XPath expressions.

I'd like to be able to use the same XPath assertion expressions in the webpage but this requires that the XPath executor have knowledge of the types of the elements. I have a patch which I have started using to achieve this here: https://gist.github.com/Parakleta/3fd775fc9170954280bb

It would be good if this functionality could please be added to the jquery.xpath library.

Thanks.

[antuanPotato]

I have used this awesome lib to test xs:assert and xs:assertion of XSD. In the app I developed a form was created based on a XSD and the user need to complete the form. First of all I modified the lib so I can test an assertion multiple times but only parsing it test attribute once. Then I came to the same problem you are describing: the lib is not aware of the Xpath Data Model as it is independent of the XSD.

So for me this would be a cool feature.

Awesome patch by the way: simple and powerful. It seems easy to extend it to make it work also to annotate attributes types (case 2). I don't think this or something similar should be used for simple types derived by xs:list as those are not atomic, but I am not sure of that, what do you think?

[ilinsky]

@Parakleta

1. Can you please provide with your patch usage scenarios? I am looking into your implementation, but also trying to match it with capabilities [possibly missing implementation] of already available APIs on StaticContext: setDataType/getDataType.
2. Do you extend your custom types on built into the XPath 2 library data types?

[Parakleta]

1. I had a look at the StaticContext methods but then thought that since the library may be used on different documents and different contexts within each document it was better that the types be part of the query (this also gives the most flexibility in complex situations that might otherwise require full PSVI, such as when the type depends on the context of the node within the document).

2. I'm not currently using any custom types, I just left that possibility in my patch. I think it should allow for handling Union types cleanly. It should also allow for pre-processing the textContent and maybe mapping it into the built-in types (date time conversions maybe?). In my current implementation I just return the string key for the built-in types.

Importantly, to implement any custom types a getter method for accessing the built-in types would be required as they're currently not exposed. I haven't considered a solution to this yet. Maybe this could be integrated with an improvement to the StaticContext getDataType and setDataType methods (or at least their exposure).

[ilinsky]

@Parakleta

with https://github.com/ilinsky/xpath.js base library:

1. you can use different static context objects both in compile() and evaluate() functions.

2. can you please clarify about unit types, I am not sure I can follow. Why do you need to preprocess textContent (for elements), value for attributes etc.?

Also, you can get references to built-in types using getDataType(). The argument takes "{namespace}localName" encoded type name.

[Parakleta]

I know the capabilities are available in the base library, I just like the JQuery version better for convenience. I did play with the getDataType() method but the only way I could access it was to monkey-patch my way in through function.arguments.caller which obviously isn't a real solution.

Regarding union types and preprocessing textContent I don't actually have anything in mind at this stage, but for example if you had an element which could contain a number or a string (for example clothing sizes, being numeric or 'S', 'M', 'L' etc.) you could then choose the type based on the content.

The other case of changing the textContent would only come about if someone wanted to use XPath expressions on an element that wasn't really the correct type. For example, manipulating a datetime field which lacked the 'T' separator or was in some other incompatible format, you could convert it to the correctly formatted string before calling the datetime constructor. This use-case doesn't apply to me because I am only using schema-validatable documents.