RE: Options for dealing with IDs

Paul,

Sure XPointer looks at the infoset.  But how does the infoset get the idattr
property?  If I build a streaming parser for XPointer that uses xml:idattr,
I've got to scan every element for an idattr attribute when looking for IDs.
For example:
<myxml>
 <child1>
   <grandchild1>
     <greatgrandchild xml:idattr="name">
        <greatgreatgrandchild name="3">

I'm not saying this is an insurmountable problem.  It just is a deficiency.

Though this deficiency would be somewhat nullified if xml:base was also
adopted, as the parser has to scan for both base and idattr attributes.

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 1:57 PM
> To: www-tag@w3.org
> Subject: RE: Options for dealing with IDs
>
>
>
> At 13:45 2003 01 07 -0800, David Orchard wrote:
>
> >Another potential aspect to look at is how XPointer would
> deal with these
> >various approaches.  Perhaps show how XPointer is affected by each,
> >particularly for bare names.  For example, Option #1, #8 has the
> >disadvantage that it means XPointer requires DTD or Schema
> validation.
> >Option #5, #6 has the disadvantage that the XPointer parser
> has to look at
> >the xml:idattr to figure out what the id attribute name is.
>
> I don't think XPointer looks at xml:idattr any more than
> it looks at, say, xml:base.  It looks at the infoset.
>
> All we'd have to say in a new little xml:id-ish spec
> is that xml:idattr adds a few pieces of information to
> the infoset (that, to date, only comes from the DTD),
> and there need be no change to XPointer.
>
> paul
>
>

Received on Tuesday, 7 January 2003 17:19:15 UTC