[oXygen-user] Content completion & nested dependencies

[John Madden]

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
>>>> 
>>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>>> _______________________________________________
>>> oXygen-user mailing list
>>> 
>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user