A core xpath plugin is a good idea.
The XML format looks fine to me, but there may be one point to consider. The number of functions added to the extension point could potentially be quite high, which means a lot more parsing for Eclipse to do when it loads plugin.xml, which could slow down Eclipse startup times even more! If instead we were to put the XML into a separate file that is only loaded when the plugin is activated, then this would not affect Eclipse's startup time.
----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Sunday, 3 February, 2008 3:26:39 AM
Subject: [wtp-incubator-dev] XPath Content Assistance
One of the things we are eventually going to need to look into is XPath
content assistance. For this I think we need to do an extension point
that can be used by both the XPath Navigator as well as the XSLT (and
possible future XQuery) editor.
Since currently there is no standard way to retrieve a list of XPath
expressions, and with XSLT 2.0 and XQuery you can create your own
dynamically, we need a pretty generic way to get the list.
So, here is a proposed XML file that could be made into a Extension:
<xpathfunctions version="1.0">
<xpath
type="Nodeset">
<name>last</name>
<definition source="
http://www.w3.org/TR/xpath">
Returns a number equal to the context size from the _expression_
evaluation context.
</definition>
<returns>
<datatype>number</datatype>
</returns>
</xpath>
<xpath type="Nodeset">
<name>position</name>
<definition source="
http://www.w3.org/TR/xpath">
Returns a number equal to the context position from the
_expression_ evaluation context.
</definition>
<returns>
<datatype>number</datatype>
</returns>
</xpath>
<xpath type="Nodeset">
<name>count</name>
<definition source="
http://www.w3.org/TR/xpath">
Returns a number equal to the context position from the
_expression_ evaluation context.
</definition>
<arguments>
<datatype>nodeset</datatype>
</arguments>
<returns>
<datatype>number</datatype>
</returns>
</xpath>
<xpath type="Nodeset">
<name>id</name>
<definition source="
http://www.w3.org/TR/xpath">
The id function selects elements by their unique ID. It
returns a node-set.
</definition>
<arguments>
<datatype>object</datatype>
</arguments>
<returns>
<datatype>nodeset</datatype>
</returns>
</xpath>
<xpath type="String">
<name>concat</name>
<definition source="
http://www.w3.org/TR/xpath">
The concat returns the
concatenation of it's arguments.
</definition>
<arguments>
<datatype>string</datatype>
<datatype>string</datatype>
<datatype>string</datatype>
</arguments>
<returns>
<datatype>nodeset</datatype>
</returns>
</xpath>
</xpathfunctions>
Basically, there would be a base definition of the existing XPath
functions that are supported. If a particular XSLT processor or even if
EXSLT needs to be supported, those processor specific extensions can be
described using the above xml file.
Anyways, tossing this out to stimulate some discussion and content.
Also, dates to keep in mind,
Feb 11th is Testing week, Feb 18th is when
the next milestone is to be declared.
Dave
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev