Re: Are we losing out because of grammars?

["K.Kawaguchi" <k-kawa@bigfoot.com>]

> A second scan is quite a big price to pay.  How do you store the result
> of the type assignment? If you keep in memory, that would mean you would
> be using memory proportional to the size of the input document, wouldn't
> it?

Exactly. And that's where "effortlessness" (or TDLL(1)) comes into play.


> > In other words, I think it's sufficient too, but I don't even want to
> > see the ancestor information. If I can receive type, all I need to see is
> > the type.
> 
> Here I don't agree.  In general I think I may need to look at ancestor

I see. You're right.


> That's not quite what I'm after.  I'm more interested in reporting
> datatypes than I am in reporting labels, so I want to know whether I can
> report datatypes unambiguously regardless of whether I can report labels
> unambiguously.  For example, given the following TREX pattern

Your problem statement is well understood. So in your view,
"interpretation" of TREX is just datatype for every attribute and some
text, right?


Well, I need some time to think about. Off the top of my head, datatype
ambiguity and label ambiguity are essentially the same thing.


<choice>
  <element name="e">
    <attribute name="a" type="integer" />
    <ref name="foo" />
  </element>
  <element name="e">
    <attribute name="a" type="string" />
    <ref name="bar" />
  </element>
</choice>

Because for the case like this, the algorithm have to check whether those
two "e" are ambiguous, to determine datatype ambiguity.

So my impression is that the algorithm will be very naive (powerless?)



regards,
----------------------
K.Kawaguchi
E-Mail: k-kawa@bigfoot.com