Re: Options for dealing with IDs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ noah_mendelsohn@us.ibm.com was heard to say:
| I think I agree with Tim's other conclusion:  do nothing is probably the 
| least risky solution.  We've got too many typing mechanisms already.

I have mixed feelings, but I think I agree with Tim and Noah.

"IDness" is a consequence of validation. That means you have to
validate. I understand that sometimes has painful consequences. If a
language wants to have IDs so that authors can point into documents,
the workaround is to establish a MIME type for that language and
describe what fragment identifiers mean independent of validation.
Similarly, the semantics of intra-document references could be defined
independent of validation if necessary.

One of the reasons I have mixed feelings is that the preceding
description doesn't sit very well with me. I think it's unfortunate
that we've got an extensible markup language but we're encouraging
everyone that uses it to invent a new MIME type. I thought, once, that
an extensible markup language would automatically give us a uniform
fragment identifier syntax, but I regret that appears not to be the
case.

On the other hand, one of the consequences xml:idAttr (and do a lesser
extent xml:id) that bothers me is that it moves this validation
semantic out into authoring space. One of the reasons that W3C XML
Schema says that schema location information is only a hint is so that
I can apply my own schema independent of what the author asked for.
Well, what if I want to use some other attribute as an ID sometimes?
It just seems to me that moving IDness into the document is a fairly
significant can of worms.

If pushed, I think I could come to terms with the simple xml:id
proposal, but the more complex variants look like too much complexity
to me.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | Truth lies within a little uncertain compass,
XML Standards Architect | but error is immense.
Web Tech. and Standards |
Sun Microsystems, Inc.  | 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+HvFBOyltUcwYWjsRAkP0AKCZksDtUg7nGF1XCfjvgDpRU7FikACgqxYE
jMbHK2u8OsUz1NIy4TiVbo4=
=JSSa
-----END PGP SIGNATURE-----

Received on Friday, 10 January 2003 11:14:02 UTC