[oXygen-user] Content completion & nested dependencies

[George Cristian Bina]

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
>