[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Type-assignment

• From: Murata Makoto <mura034@a...>
• To: Kohsuke KAWAGUCHI <k-kawa@b...>
• Date: Sat, 03 Feb 2001 10:04:43 +0900

I would rather create the intersection/differences of labels.

In your example, the hedgeRule for catalyst has <choice>.  
Thus, you were able to merge the two labels.

Suppose we modify this hedgeRule as below:

<hedgeRule label="catalyst">
  <sequence>
    <ref label="foo" occurs="?"/>
    <ref label="bar" occurs="?"/>
  </sequence>
</hedgeRule>

This grammar is still ambiguous.

We have to rewrite all rules as below:

-------------------------------------------
<hedgeRule label="catalyst">
  <sequence>
    <choice occurs="?">
      <ref label="foo-and-not-bar"/>
      <ref label="foo-and-bar"/>
    </choice>
    <choice occurs="?">
      <ref label="bar-and-not-foo"/>
      <ref label="foo-and-bar"/>
    </choice>
  </sequence>
</hedgeRule>

<elementRule label="foo-and-bar" role="foo">
  exp1
</elementRule>

<elementRule label="foo-and-not-bar" role="foo">
  exp2
</elementRule>

<elementRule label="bar-and-not-foo" role="bar">
  exp3
</elementRule>

-------------------------------------------

Here, exp1 represents the intersection of <hedgeRef label="foo.model"
occurs="?" /> and <hedgeRef label="bar.model" occurs="?" />.  Since
RELAX does not have <concur> of TREX, computation of exp1 is not
straightforward.  That is, we have to compute an intersection hedge
automaton and then converts it to RELAX.  Unfortunately, this will 
cause significant changes to labels.

We take <hedgeRef label="bar.model" occurs="?" /> from <hedgeRef
label="foo.model" occurs="?" /> , and the remainder is exp2.  We take
<hedgeRef label="foo.model" occurs="?" /> from <hedgeRef
label="bar.model" occurs="?" />, and the remainder is exp3.  Again,
this will cause significant changes to labels.

If RELAX borrows <concur> of TREX and introduces <difference>, 
we can avoid significant changes to labels.

Cheers,

Makoto

• Follow-Ups:
  • Re: Type-assignment
    • From: "K.Kawaguchi" <k-kawa@b...>

• References:
  • Re: Type-assignment
    • From: Kohsuke KAWAGUCHI <k-kawa@b...>

• Prev by Date: Re: Type-assignment
• Next by Date: Re: XML versus Relational Database
• Previous by thread: Re: Type-assignment
• Next by thread: Re: Type-assignment
• Index(es):
  • Date
  • Thread