[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Are we losing out because of grammars?
- From: "K.Kawaguchi" <firstname.lastname@example.org>
- To: James Clark <email@example.com>
- Date: Fri, 02 Feb 2001 10:55:54 -0800
> 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
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
Well, I need some time to think about. Off the top of my head, datatype
ambiguity and label ambiguity are essentially the same thing.
<attribute name="a" type="integer" />
<ref name="foo" />
<attribute name="a" type="string" />
<ref name="bar" />
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?)