You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vxquery.apache.org by "Vinayak Borkar (JIRA)" <ji...@apache.org> on 2009/10/20 22:32:59 UTC
[jira] Created: (VXQUERY-16) Externalize use of Name Cache
Externalize use of Name Cache
-----------------------------
Key: VXQUERY-16
URL: https://issues.apache.org/jira/browse/VXQUERY-16
Project: VXQuery
Issue Type: Improvement
Reporter: Vinayak Borkar
Assignee: Paul Fremantle
QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VXQUERY-16) Externalize use of Name Cache
Posted by "Vinayak Borkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VXQUERY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779737#action_12779737 ]
Vinayak Borkar commented on VXQUERY-16:
---------------------------------------
Good point. Let us break the Manipulator interfaces at the type boundaries.
The types like durations/datetime etc bother me too. Its a pain in the butt to get right, and I am willing to make the assertion that there are a countable few who would be willing to do so. We could get them to explore ways of refactoring VXQuery to include their implementation.
I think we will need a "meet-in-the-middle" approach -- some types can be fully externalized and some types will be translated into VXQuery's representation. I think this is going to be an engineering decision.
Strings/Numbers are on one side and Datetimes/durations are on the other. The hardest type to decide on is the QName -- Its common enough that you want a really fast implementation, while not making too many assumptions about how it is implemented -- That's the oxymoron.
> Externalize use of Name Cache
> -----------------------------
>
> Key: VXQUERY-16
> URL: https://issues.apache.org/jira/browse/VXQUERY-16
> Project: VXQuery
> Issue Type: Improvement
> Reporter: Vinayak Borkar
> Assignee: Vinayak Borkar
>
> QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (VXQUERY-16) Externalize use of Name Cache
Posted by "Vinayak Borkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VXQUERY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vinayak Borkar reassigned VXQUERY-16:
-------------------------------------
Assignee: Vinayak Borkar (was: Paul Fremantle)
> Externalize use of Name Cache
> -----------------------------
>
> Key: VXQUERY-16
> URL: https://issues.apache.org/jira/browse/VXQUERY-16
> Project: VXQuery
> Issue Type: Improvement
> Reporter: Vinayak Borkar
> Assignee: Vinayak Borkar
>
> QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VXQUERY-16) Externalize use of Name Cache
Posted by "Vinayak Borkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VXQUERY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779635#action_12779635 ]
Vinayak Borkar commented on VXQUERY-16:
---------------------------------------
This is a complex issue and I think it would be beneficial to discuss its design on before I make changes.
The tasks to be performed are as follows:
1. Create a new interface called "DatamodelStaticInterface" -- Every datamodel implementation would have an implementation of this interface.
2. Currently atomic values are implemented as concrete classes. There is also a concrete implementation called AtomicValueFactory.
The idea here is to create an interface called AtomicValueFactory and have the current AtomicValueFactory be a class that implements that interface and generates the classes that it currently generates. Going forward, we should move away from requiring atomic values implement any particular interface. Instead, we would have an interface say "AtomicValueManipulator" that implemnents all the interfaces that the engine requires to work correctly.
For e.g., instead of o.getDMOKind(), we would call m.getDMOKind(o), where m is an implementation of the Manipulator interface. The instance of the manipulator interface would be obtained from the DatamodelStaticInterface. This allows datamodel implementers to use their own objects as long as they can discern them at the XQuery level.
I am looking for more comments on the issue.
> Externalize use of Name Cache
> -----------------------------
>
> Key: VXQUERY-16
> URL: https://issues.apache.org/jira/browse/VXQUERY-16
> Project: VXQuery
> Issue Type: Improvement
> Reporter: Vinayak Borkar
> Assignee: Vinayak Borkar
>
> QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VXQUERY-16) Externalize use of Name Cache
Posted by "Till Westmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VXQUERY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779706#action_12779706 ]
Till Westmann commented on VXQUERY-16:
--------------------------------------
One of the issues could be that the Manipulator interface gets quite big, if it is the union of all AtomicValue sub-interfaces. So we might want to consider breaking it up.
Another question would be how far the Manipulator interface would go. E.g. today we have direct access to the Duration value of the DurationValue class and we make some use of it to implement arithmetic operations efficiently.
One solution would be to provide a similar method on the Manipulator interface and to implement the arithmetic operations for all DM implementations based on the Duration values. But for a DM representation that does not use Duration objects internally, it would be some evaluation overhead to create those.
Another solution would be to also move the arithmetic operations into the manipulator interface, allowing for more efficiency, but also requiring more implementation effort for each DM implementation.
> Externalize use of Name Cache
> -----------------------------
>
> Key: VXQUERY-16
> URL: https://issues.apache.org/jira/browse/VXQUERY-16
> Project: VXQuery
> Issue Type: Improvement
> Reporter: Vinayak Borkar
> Assignee: Vinayak Borkar
>
> QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (VXQUERY-16) Externalize use of Name Cache
Posted by "Vinayak Borkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VXQUERY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on VXQUERY-16 started by Vinayak Borkar.
> Externalize use of Name Cache
> -----------------------------
>
> Key: VXQUERY-16
> URL: https://issues.apache.org/jira/browse/VXQUERY-16
> Project: VXQuery
> Issue Type: Improvement
> Reporter: Vinayak Borkar
> Assignee: Vinayak Borkar
>
> QName management currently uses Name Caches. This needs to be externalized to the datamodel implementation. The core system should have a generic way of representing QNames
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.