- From: David Orchard <dorchard@bea.com>
- Date: Tue, 7 Jan 2003 14:47:55 -0800
- To: <www-tag@w3.org>
I agree we are talking about things on different planes. I care about how an actual parser would work, not just how specs work. And I believe it's important to consider the impact on building parsers. I consider the infoset a glossary, not an encapsulation mechanism/magic layer that means we can or should ignore how the parser is built. Cheers, Dave > -----Original Message----- > From: www-tag-request@w3.org > [mailto:www-tag-request@w3.org]On Behalf Of > Paul Grosso > Sent: Tuesday, January 07, 2003 2:28 PM > To: www-tag@w3.org > Subject: RE: Options for dealing with IDs > > > > At 14:18 2003 01 07 -0800, David Orchard wrote: > > >Sure XPointer looks at the infoset. But how does the > infoset get the idattr > >property? > > Maybe we are discussing things on different planes. > > You appear to be talking about writing code to process > XPointers by looking at raw XML. > > I'm talking more about the specs. > > My point is that the XPointer specs are already written > based on the infoset, and they (as specs) don't need to > care how things got into the infoset. > > > If I build a streaming parser for XPointer that uses xml:idattr, > > If you build something that isn't an XML parser, you're on your own. > I see no reason for W3C specs to care about that scenario. > > If you build an XML parser and it doesn't provide the infoset with > the necessary values, then that parser cannot be used in applications > that require such values. The XPointer specs right now make clear > what values they require from the infoset. A processor that doesn't > provide the necessary infoset is not a compliant XPointer processor. > > paul > >
Received on Tuesday, 7 January 2003 17:48:43 UTC