Re: Options for dealing with IDs

From: "Norman Walsh" <Norman.Walsh@Sun.COM>

> "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.

I agree.

Not blaming you personally, but your employer must carry much of the blame
for the course of events. If they had not protested so strongly at an early
stage about XML applications using the application/xml media type, we would
never have set up the ietf-xml-mime list, which led to the creation of RFC
2376 (XML Media types).

> 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.

Actually xml:id doesn't *necessarily* break this. An attribute called xml:id
will always be of type ID, but not all attributes of type ID have to be
called xml:id. So if you want the property you describe above, by all means
use other names.

> 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.

One of the reasons I prefer xml:id is that it works with current software:
just add it to the DTD and go (if the processor doesn't read the DTD it
needs built-in knowledge of the ID attributes anyway), and it doesn't get in
the way of composibility (which an attribute on the root element does).

Steven Pemberton

Received on Tuesday, 21 January 2003 07:02:18 UTC