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