RE: Options for dealing with IDs

Norm,

I really agree with you on this issue about MIME type, IDs and frag
identifiers.  This issue is a significant reason why various groups have to
create and register MIME-types, when the probably wouldn't have to.  An
example is the WSD working group.  Now they might have to anyway because
they want a different kind of ID mechanism (names, with context sensitive
name referencing).  But I postulate that if there was a solution to the
ID/frag id issue, they would seriously rethink creating their own MIME type
and frag identifiers.

One of the ways that I look at architecture, is how can I solve a problem in
1 place instead of n places.  Re-use and all that.  I agree that there is a
certain amount of "validation" logic to ids, so an xml:id isn't
architecturally pure.  But it seems like a really great 80/20 trade-off to
make, given the # of places that are defining their own IDs, mime types,
frag identifier syntax and not requiring dtd/schema/relax validation.

Cheers,
Dave



> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Norman Walsh
> Sent: Friday, January 10, 2003 8:14 AM
> To: www-tag@w3.org
> Subject: 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 14:03:53 UTC