Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XPath function for accessing FeatureTypes from Schema #37

Open
jonherrmann opened this issue Jun 24, 2016 · 6 comments
Open

XPath function for accessing FeatureTypes from Schema #37

jonherrmann opened this issue Jun 24, 2016 · 6 comments
Assignees
Labels
importance: medium Leave a comment if you think the importance is higher module: BSX-TD BaseX Test Driver module: SUI-TD SopUI Test Driver stale Type: create EIP Create an EIP for this Enhancement Type: Discussion Input is required. Requirements and/or importance may be unclear

Comments

@jonherrmann
Copy link
Collaborator

jonherrmann commented Jun 24, 2016

This enhancement requires the implementation of a XQuery module that can be loaded by BaseX-based ETSs. The module should provide XPath functions for determining all FeatureTypes in an XML document by reading and analysing the associated schema.

  1. A schema-element() function is required https://www.w3.org/TR/xpath20/#id-schema-element-test . Note: for performance reasons this is not implemented by BaseX itself.
  2. The function call etf:feature-members( rootNodeOrSchemaLocation ) should return a sequence of all Feature member nodes in the Feature Collection.
  3. The function call etf:feature-type-names( rootNodeOrSchemaLocation ) should return a sequence of strings with the names of all Feature Type names.

See also: http://docs.basex.org/wiki/Java_Bindings

@jonherrmann jonherrmann self-assigned this Jun 24, 2016
@cportele cportele added Type: create EIP Create an EIP for this Enhancement importance: medium Leave a comment if you think the importance is higher labels Feb 1, 2017
@jonherrmann jonherrmann added the Type: Discussion Input is required. Requirements and/or importance may be unclear label Apr 7, 2017
@michellutz
Copy link

@jonherrmann, as discussed during the 2017.4 meeting on 2018-03-16, please elaborate a little bit on what needs to be done to implement this change.

@jonherrmann
Copy link
Collaborator Author

@michellutz updated the description.

@cportele
Copy link
Contributor

@jonherrmann @michellutz

I think one of the original ideas was to support a similar capability to schema-element() from XSLT, too. This would be useful when testing INSPIRE data that uses an extension.

The current situation is that the ETSs use local element names to identify feature instances of a specific feature type. Ie. the ETSs will also identify and test features of feature types that include a few additional attributes in the namespace of an extension. These feature types will have the same local name as they implement the same feature concept (if the extension follows the conceptual model). However, proper specialisations of the INSPIRE feature type will typically receive different local names and cannot be detected as subtypes of an INSPIRE feature type by looking at the element name. Schema analysis is required.

The approach described in the initial description does not seem to support this. Or has it been discussed in Ispra that the current support for extensions is sufficient?

@jonherrmann
Copy link
Collaborator Author

@cportele maybe the wording 'by parsing the associated schema' is not clear enough -'reading and analyzing' might have been better- but under the hood this functionality requires a similar capability to the schema-element() function.

So the result of //schema-element(gml:AbstractFeature)would be equal to etf:feature-members( / ) . Would this be OK?

I will also add the schema-element() function to the numbered list in the description, so that it can be used for other types of tests.

@cportele
Copy link
Contributor

Yes, etf:feature-members( / ) is the same as //schema-element(gml:AbstractFeature), but for the ETSs the typical expression needed would be something like //schema-element(ps:ProtectedSite) (where protected site is an example) - or even better something like $features[etf:is-kind-of(., ps:ProtectedSite)] or similar.

@jonherrmann
Copy link
Collaborator Author

Ah, that makes sense -sorry, I overlooked that part..

@jonherrmann jonherrmann added module: SUI-TD SopUI Test Driver module: BSX-TD BaseX Test Driver labels May 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
importance: medium Leave a comment if you think the importance is higher module: BSX-TD BaseX Test Driver module: SUI-TD SopUI Test Driver stale Type: create EIP Create an EIP for this Enhancement Type: Discussion Input is required. Requirements and/or importance may be unclear
Projects
None yet
Development

No branches or pull requests

3 participants