W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

RE: Options for dealing with IDs

From: David Orchard <dorchard@bea.com>
Date: Tue, 7 Jan 2003 14:47:55 -0800
To: <www-tag@w3.org>
Message-ID: <029e01c2b69e$d1eca4b0$9d0ba8c0@beasys.com>

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.


> -----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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:56 UTC