Re: xml:id versus xmlid

/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
|> From: public-xml-core-wg-request@w3.org On Behalf Of Paul Grosso
|> Sent: Monday, 25 April, 2005 8:57
|> To: public-xml-core-wg@w3.org
|> Subject: Agenda for XML Core WG telcon of 2005 April 27
|
|> 7. xml:id.
|
| Actually, I should have mentioned that a thread has
| started on public-xml-id arguing again for xmlid 
| instead of xml:id.  I suspect we will be asked again
| about this on the PR call.
|
| See
| http://lists.w3.org/Archives/Public/public-xml-id/2005Apr/0013
| and followup.

I never received any message on this thread. At all. Very odd. I have
received other recent messages on the public-xml-id comments list so I
guess I'll just imagine it was a one-off. Unfortunately, I burned my
spam bucket before I realized I'd missed these messages so there's no
way for me to check that now.

With respect to the discussion, I don't know what to say.

> 'xml:id' invokes a level of complexity not necessary for simple
> situations. "xml:id" seems preferred by the "industrial strength"
> folks, and I understand why, but the concept of an ID is so basic and
> fundamental that it should be usable by everybody, not just by the
> folks that understand and step up to the nuances of namespaces.

This is simply misleading. The name xml:id requires no additional
complexity over the name xmlid. By analogy, the concept of an
element's natural language or the significance of whitespace in the
element "is so basic and fundamental that it should be usable by
everybody" and *it is* with attributes named xml:lang and xml:space.

> XML started small and simple.  Today it is large and complex.  

*Shrug*. The XML Recommendation is not significantly larger nor more
complex today than it was in 1998. The apparent complexity of XML is
mostly a consequence of the union of a whole bunch of different
specifications. If you don't need them, don't use them, and life will
be simpler. If you do need them, then life must already be complicated
for you.

> Still, folks with simple problems try to use it without a Master 
> of Science in XML.  ...and well they should.  An ID attribute for 
> simple situations should remain simple.  'xml:id' doesn't do that.

Yes, it does.

> How about allowing
> both? Simple situations could use 'xmlid' and those needing
> "industrial strength" namespaces could use 'xml:id', although XPath
> would still be the best choice. Yes? No?

No. *Anything* but that.

> So, as soon as your XML application gets a bit more complicated and
> you have to deal with namespaces, schemas and infosets, xml:id has to
> be treated as an exception, where xmlid would be just another
> attribute.

All of the xml:* namespaced attributes are an exception and they
already exist. The name xml:id adds nothing new on that score.

> With xml:id, you may end up with multiple IDs on the same element.

That will be no more or less true if we name it "xmlid".

> xml:id may even occur under another name, such as
> foo:id, in a namespace-aware document.

No, it may not. That is forbidden.

> So, all in all, It seemed so much easier to deal with xmlid.
> The arguments of the WG didn't convince me, but I've given up.

Yeah, well, I don't find the argument "it seemed so much easier to
deal with xmlid" convining. In fact, I can't think of anywhere 


> xml:id is in fact not parallel to xml:space and xml:lang. It has
> different inheritance behavior, and therefore should not be treated
> the same. 

Knowing now what we know about C14N makes this argument much more
compelling to me than it used to be.

> The only reason to use xml:id is an adamant belief that all names
> should have colons in them.

Well, no, I don't think that's the only reason. The xml:id attribute
is intended to be a global attribute and "global" attributes are in a
namespace (as opposed to "local" attributes which are never in a
namespace). Certainly the schema documents for xml:id and xmlid would
be quite different.

Users are already used to the fact that the xml: namespace is
reserved. While it's true that all names starting "xml" are reserved,
I think some folks are going to be confused if we assert rights to
attributes that they think of as local.

> [ Elliotte and Chris exchanged a series of messages ]

A selection of arguments and my thoughts:

| xml:id is not parallel to xml:space and xml:lang because it doesn't
| inherit

I suppose.

| //*/@xml:id when xml: is not bound.

XPath context/API initialized incorrectly. Bug.

| //*/@foo:id when foo: is bound to the XML Namespace URI.

XPath context/API initialized incorrectly. Bug.

| //*/@xmlid has no such ambiguity

True, bugs or otherwise.

| While it's true that all these problems with xml:id already exist
| with the other xml:* attributes, we aren't actually compelled to
| repeat the mistakes of the past.

It's true that we aren't compelled to use the name xml:id, though
clearly there are folks who aren't convinced that xml:id is a mistake.

| The assumption that xml:* attributes are inherited is out there,
| it's wrong to put a non-inheritable attribute in there.

Problematic, anyway. But all of the problems are in one spec that is,
in my humble opinion at least, broken irrespective of what we call the
global XML ID attribute.

| The xml:* mechanism is fundamentally broken and should never be used
| again

Some people feel that way, some don't. 

| With xml:id we're moving deeper into territory where libraries
| actually care about what happens.

True.

On the whole, I don't think I've been quite convinced.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.