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

[David Brownell <david-b@pacbell.net>]

> It isn't wrong, but multiple IDs are really multiple 
> locator targets.

What's "it"?   What do you even mean by "locator"?

There are dozens of ways to identify most anything;
multiple IDs per object are the norm. Say, a house:

    - 1152 Main Street
    - Blue house next to Karen's
    - Corner of Main and High
    - Dan's place
    - That house there (pointing).
    - ... more

Same thing (same "locator target" or object "identity"),
multiple names/IDs.  Over time, some of the names change
meaning: color changes, owners move, sometimes even
houses move, etc.  One goal is to use a name that stays
bound to the right object for as long as appropriate.
Another is being able to update name-to-object bindings
so that they work as intended.


>     it seems we should separate 
> this from the notion of multiple IDs which to me,
> feels more like a set of secondary keys: that is, 
> a unique ID is one per, yet other keys can exist 
> as members of some set for use in a different location 
> operation.

Curious.  I've never yet wanted to think about XML IDs
like relational database keys, with some "more equal".


> The concept of address target of the locator, is well-understood.  

Widely, but not uniformly so.  Addressing and naming are
fundamental issues, and if you can't get a good flamewar
going on them you haven't tried.  (Quick, explain how a URI
is different from a URL is different from a URN ... :)  There
isn't agreement on all terminology, for starters.


> The sort of thing you are asking for as I recall was called 
> a nameloc.  ... Groves are in themselves, a good 
> idea, but seem to race past the problem.

http://info.admin.kth.se/SGML/Anvandarforening/Arbetsgrupper/HyTime/Reports/tr1v1.html#addressing

talks a bit about nameloc.  (Google!)  Very different issue;
it seems to accept the "one ID per element" premise.
Unlike, for one widely used example, the Real World! :)


> A position is not an address.  A position is one kind of 
> property to create an address.  Treelocs, for example, 
> or rellocs...

Depending on definitions you adopt, a position is certainly
a kind of relative address:  "third house on the left", "third
sect3 child of this sect2".  For XML documents, these
are not "stable" in the face of many common mutations
(stick this sect3 in before that one).


> For now, the problem at hand seems to be Xpointers.

As in, XPointer is excessively complex, and expects too
much infrastructure?  :)

- Dave



> I think the problem is needing stable node identifiers (by name/role)
> that don't force document authors to declare them in internal subsets
> (or use Schema-du-jour) to ensure that minimally conformant XML
> parsers will see the decls.  So the question becomes where they get
> identified.  A "global" definition, like an "xml:ids" attribute, seems to
> be the least invasive/error-prone solution yet proposed.
> 
> - Dave
>