Re: [xml-dev] Re: determining ID-ness in XML

[Bob Hutchison <hutch@xampl.com>]

Summary: I am going to suggest that the id's listed in the <?xml-typeinfo?>
should be unioned with the currently in-force set of ids. If it is felt that
it is important to have the ability to remove ids from this list then this
should be done only on close of the containing element by reverting to the
list that was in effect when the containing element was opened.

(If namespaces are used, and id-ness is consistent within a namespace, then
I think we don't need to remove ids from the list -- this will make
everything much easier -- but then we get to talk about whether the pi
applies from the point of the pi or to the whole document).

---

Some questions...

Qa: What does the <?xml-typeinfo idnames='id'?> apply to?
1a) all child elements of the element containing the pi? or,
2a) the element containing the pi and all of its children? or,
3a) all child elements of the element containing the pi from the point of
the pi?  or,
4a) all elements from the pi to the end of the document?
5a) the whole document

Qb: How does the list of ids in the <?xml-typeinfo idnames='id'?> affect the
list currently in force?
1b) by replacement? or,
2b) by union?

Qc: How does namespace play in all this? and which namespace are we talking
about? (element's or attribute's)

Qd: Why are we so determined to remove attributes from the id list anyway?

Qe: Are we concerned with SOAP being able to play?

A few comments...

C1: 1a & 2a don't care about where in the element the pi is placed within
the element, and they have to deal with more than one pi.

C2: If the pi applies to the containing element (2a) then we have something
similar to the xml:idattr='' proposal I think. Unfortunately, if we have an
element that is supposed to be empty and also with an id we run into
difficulties. It is my understanding that <e name='123'><?xml-typeinfo
idnames='name'?></e> is not empty. So we cannot have (given 2a):

    <a id='1'>
        <e id='123'/>
    </a>

Where the name on <e> is an id, but on <a> it is not.

C3: There is no relationship between the structure of the element and the pi
in 3a and none between the structure of the *document* and the pi in 4a.
Personally, this makes me nervous.

C4: Leaving us with 1a which raises the question of what happens when there
are two pi's in the same element? Replace or union or ignore? This depends
on the answers to the other questions.

C5: Union of the ids makes some sense if the id-ness of an attribute is
consistent in a namespace, that is if within a namespace you know that if an
attribute with a particular name is used then it is an id. It works because
there is never a need to remove the attribute from the list. This happens to
be the situation in my work so I've got a bias.

C6: Union of ids makes it much easier to hand edit an xml file as long as
when the 'scope' of the pi is left the list reverts to what it was. I've
already posted some examples. But leaves us with this example where 'name'
is an id for <a> and <c> but NOT for <b> and <d> and marking it up would be
a mess:

<doc>
    <a name='1'>
        <b name='2'>
            <c name='3'>
                <d name = 4'/>
            </c>
        </b>
    </a>
</doc>

If we have namespaces on these then we might not have the same difficulties.

C7: Replacement of ids allows you to turn off the id-ness of an attribute.
Unfortunately I think the cost of this might be prohibitive (again see the
examples posted earlier). I know this is an issue and this is a pretty lame
way of dealing with it, however, I could go on if necessary.

C8: Which namespace are we talking about? If we see <?xml-typeinfo
idnames='ns:id'?> does this apply to elements in the namespace 'ns' or to
attributes in the namespace 'ns'? I don't find this obvious at all, but then
I cannot help thinking that in <ns:a id='123'/> the namespace of id should
be ns and I know that it isn't -- so this might explain why I have this
question :-)

C9: SOAP processors upon encountering a processing instruction MUST fail or
ignore it (yes, those *are* the choices). Fail is bad for this proposal,
this means you cannot move documents marked up with processing instructions
using SOAP. Ignore is bad too -- at least one SOAP parser simply strips them
out silently.

I could go on, but I'll cut it short.

Cheers,
Bob