Re: Significant W3C Confusion over Namespace Meaning and Policy

/ Dare Obasanjo <> was heard to say:
| the problem exists. Going back to the root of this discussion
| application scenarios broke when the W3C introduced xml:base and the
| same will happen with the introduction of xml:id.

Let's see what breaks.

1. C14N breaks. I haven't heard anyone argue that the bug in C14N is
   anything but a bug. Unfortuntate, yes. Significant enough to stop
   xml:id from happening, perhaps. But let's imagine C14N didn't
   have this bug, then it'd be just fine.

2. If your application requires validity, nothing breaks. You can't use
   xml:id attributes unless you put them in your schema and if you put
   them in your schema, they'll work just like any other attributes.
   You must declare them as type ID, but that's ok because you can't
   possibly have declared them as anything else in your legacy and if you
   have other ID attributes, you don't need xml:id. It might be nice if
   you migrated to xml:id over time, but there's no pressing urgency.

3. If your application only requires well-formed documents, then xml:id
   attributes might be IDs to some processors and not others. But this
   problem already exists: some processors handle the external subset and
   some don't. (Even a non-validating parser can use the declarations
   in the internal/external subset to identify IDs.)

   The introduction of xml:id does not introduce any new problems, and
   its adoption will *reduce* (maybe eventually remove) this problem.

You say "application scenarios will break with the introduction of
xml:id." Which ones, exactly?

                                        Be seeing you,

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.

Received on Tuesday, 15 February 2005 21:35:34 UTC