Content completion & nested dependencies
Hi, This is about inaccurate content completion lists in editing XML instances associated with certain Relax NG schemas. I have some schemas that have this kind of structure: ... <element name="item"> <attribute name="name"> <value>first</value> </attribute> <element name="response"> <attribute name="value"> <choice> <value>alpha</value> <value>beta</value> </choice> </attribute> </element> </element> <element name="item"> <attribute name="name"> <value>second</value> </attribute> <element name="response"> <attribute name="value"> <choice> <value>gamma</value> <value>delta</value> </attribute> </element> </element> ... resulting in instances that look like this: ... <item name="first"> <response value="alpha"/> </item> <item name="second"> <response value="gamma"/> </item> ... What I tend to find when editing the instance, the content completion lists are accurate for //item/@name, but generally **inaccurate** for //item/response/@value. I can understand this -- the latter have a layer of dependency that the former do not. On the other hand, when I validate such an instance, the error messages I get from Jing regarding //item/response/@value always accurately enumerate the valid options. For example, this (invalid) instance: ... 1) <item name="first"> 2) <response value="gamma"/> 3) </item> 4) <item name="second"> 5) <response value="alpha"/> 6) </item> ... would get the following errors from Jing: (line 2) [Jing] value of attribute "value" is invalid; must be equal to "alpha" or "beta". (line 5) [Jing] value of attribute "value" is invalid; must be equal to "gamma" or "delta". The content completion lists usually would just show the choices pertaining to item[@name="first"]/response/@name, even when attempting to complete the value entry for item[@name="second"]/response/@value. So basically, Jing sees all the dependencies, but the content completion list algorithm does not. So my question is: would it be possible to give the content completion engine some hints from Jing, in order to improve the accuracy in cases like this where there are such dependencies? Or is there some other strategy for improving content completion in these cases? John
I have duplicated this problem using both the XML syntax and the compact syntax in oXygen 11.1 build 2009121816 on Mac OS X 10.5.8 on Intel architecture. --------- schema --------- start = element test { what } what = element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } } --------- end schema ---------
Thanks John, Syd, I will look into this shortly. The quick explanation is that for Relax NG the whole document content before the insert position can determine what is accepted next but we take only a reduced context formed by the preceding sibling elements and the ancestors. That gives the expected results almost all situations. I will see what happens exactly in this case and if we can easily correct that. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com Syd Bauman wrote:
I have duplicated this problem using both the XML syntax and the compact syntax in oXygen 11.1 build 2009121816 on Mac OS X 10.5.8 on Intel architecture.
--------- schema --------- start = element test { what } what = element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } } --------- end schema --------- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Thanks, George. This type of "nested dependency" pattern is what Eric van der Vlist calls a Relax NG "co-occurrence constraint" pattern: http://books.xmlschemata.org/relaxng/relax-CHP-7-SECT-2.html (I don't like that name very much, because I think "co-occurrence constraint" is a much broader concept than just this; I'd call it "one particular type of co-occurrence constraint that happens to be supported natively by RNG grammar".) I realize it's a tough pattern to address, because it potentially involves re-rentrant code that evaluates for dependencies among various levels of different parent hierarchies. I also understand that (per Eric van der Vlist's comments) this kind of schema pattern does not straightforwardly survive conversion to DTD or XMLSchema -- so in other words, it is primarily of interest to RNG users like me and Syd). Nevertheless, anything you could do to address it would be great. My current project uses this pattern all over the place!! John On Jan 10, 2010, at 2:46 AM, George Cristian Bina wrote:
Thanks John, Syd,
I will look into this shortly. The quick explanation is that for Relax NG the whole document content before the insert position can determine what is accepted next but we take only a reduced context formed by the preceding sibling elements and the ancestors. That gives the expected results almost all situations. I will see what happens exactly in this case and if we can easily correct that.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Syd Bauman wrote:
I have duplicated this problem using both the XML syntax and the compact syntax in oXygen 11.1 build 2009121816 on Mac OS X 10.5.8 on Intel architecture.
--------- schema --------- start = element test { what } what = element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } } --------- end schema --------- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hi John, Here it is the explanation of what happens. Suppose we have a schema like start = element root { (element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } })+ } Then for a document like <root> <item name="first"> <response value="alpha"/> </item> <item name="second"> <response value=""></response> </item> </root> when trying to insert the second value oXygen will use the following reduced context <root> <item name="second"> <response value=""> The item will be matched to the first item element and the "second" value will be ignored and that will result in "alpha" and "beta" as proposals. If the group is replaced with a choice, like below: namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" start = element root { (element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } } | element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } })+ } then oXygen will be able to identify the second item element based on the name attribute value and the proposals will be "gamma" and "delta". So, basically you hit a limitation of the content completion due to the reduced context that we use. In general for Relax NG the whole document before the insertion point determines what comes next so the best solution will be to use that as context. The reduced context that we use is formed by the previous sibling elements of the current element and all the ancestors up to the root. An improvement will be to keep also all the previous sibling elements of the ancestors, that will solve your situation and in general will give the correct proposal in more situations. Note however that the current implementation cover most of the cases. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com John Madden wrote:
Thanks, George.
This type of "nested dependency" pattern is what Eric van der Vlist calls a Relax NG "co-occurrence constraint" pattern:
http://books.xmlschemata.org/relaxng/relax-CHP-7-SECT-2.html
(I don't like that name very much, because I think "co-occurrence constraint" is a much broader concept than just this; I'd call it "one particular type of co-occurrence constraint that happens to be supported natively by RNG grammar".)
I realize it's a tough pattern to address, because it potentially involves re-rentrant code that evaluates for dependencies among various levels of different parent hierarchies.
I also understand that (per Eric van der Vlist's comments) this kind of schema pattern does not straightforwardly survive conversion to DTD or XMLSchema -- so in other words, it is primarily of interest to RNG users like me and Syd).
Nevertheless, anything you could do to address it would be great. My current project uses this pattern all over the place!!
John
On Jan 10, 2010, at 2:46 AM, George Cristian Bina wrote:
Thanks John, Syd,
I will look into this shortly. The quick explanation is that for Relax NG the whole document content before the insert position can determine what is accepted next but we take only a reduced context formed by the preceding sibling elements and the ancestors. That gives the expected results almost all situations. I will see what happens exactly in this case and if we can easily correct that.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Syd Bauman wrote:
I have duplicated this problem using both the XML syntax and the compact syntax in oXygen 11.1 build 2009121816 on Mac OS X 10.5.8 on Intel architecture.
--------- schema --------- start = element test { what } what = element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } } --------- end schema --------- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hi George, This helps, and does explain what I am seeing. The solution of wrapping these in a repeated <choice> might be possible in a few cases for my project, but it does substantively change the model, so I can't use it as a general solution. I tried to experiment with a <group> wrapper, but that doesn't help (guess it's either there already by implication, or it gets stripped out during simplification, prior to calculating completion option set). Anyway, I'll live with the limitations if I have to, but if there's any easy way to expand the context used to compute the completion set, that would be great. (If it requires a lot of new code, I certainly understand that's probably not in the cards. I can also imagine that even if it doesn't require a lot of new code, the increased computations might make content completion less responsive, so perhaps expanded context might just be a user option...) Anyway, if it doesn't require major internal overhaul of the code, I'd certainly be delighted to see it fixed. John On Jan 11, 2010, at 5:37 AM, George Cristian Bina wrote:
Hi John,
Here it is the explanation of what happens. Suppose we have a schema like
start = element root { (element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } })+ }
Then for a document like
<root> <item name="first"> <response value="alpha"/> </item>
<item name="second"> <response value=""></response> </item> </root>
when trying to insert the second value oXygen will use the following reduced context
<root> <item name="second"> <response value="">
The item will be matched to the first item element and the "second" value will be ignored and that will result in "alpha" and "beta" as proposals.
If the group is replaced with a choice, like below:
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
start = element root { (element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } } | element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } })+ }
then oXygen will be able to identify the second item element based on the name attribute value and the proposals will be "gamma" and "delta".
So, basically you hit a limitation of the content completion due to the reduced context that we use. In general for Relax NG the whole document before the insertion point determines what comes next so the best solution will be to use that as context.
The reduced context that we use is formed by the previous sibling elements of the current element and all the ancestors up to the root. An improvement will be to keep also all the previous sibling elements of the ancestors, that will solve your situation and in general will give the correct proposal in more situations. Note however that the current implementation cover most of the cases.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
John Madden wrote:
Thanks, George. This type of "nested dependency" pattern is what Eric van der Vlist calls a Relax NG "co-occurrence constraint" pattern: http://books.xmlschemata.org/relaxng/relax-CHP-7-SECT-2.html (I don't like that name very much, because I think "co-occurrence constraint" is a much broader concept than just this; I'd call it "one particular type of co-occurrence constraint that happens to be supported natively by RNG grammar".) I realize it's a tough pattern to address, because it potentially involves re-rentrant code that evaluates for dependencies among various levels of different parent hierarchies. I also understand that (per Eric van der Vlist's comments) this kind of schema pattern does not straightforwardly survive conversion to DTD or XMLSchema -- so in other words, it is primarily of interest to RNG users like me and Syd). Nevertheless, anything you could do to address it would be great. My current project uses this pattern all over the place!! John On Jan 10, 2010, at 2:46 AM, George Cristian Bina wrote:
Thanks John, Syd,
I will look into this shortly. The quick explanation is that for Relax NG the whole document content before the insert position can determine what is accepted next but we take only a reduced context formed by the preceding sibling elements and the ancestors. That gives the expected results almost all situations. I will see what happens exactly in this case and if we can easily correct that.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Syd Bauman wrote:
I have duplicated this problem using both the XML syntax and the compact syntax in oXygen 11.1 build 2009121816 on Mac OS X 10.5.8 on Intel architecture.
--------- schema --------- start = element test { what } what = element item { attribute name { "first" }, element response { attribute value { "alpha" | "beta" } } }, element item { attribute name { "second" }, element response { attribute value { "gamma" | "delta" } } } --------- end schema --------- _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (3)
-
George Cristian Bina -
John Madden -
Syd Bauman