It sounds like we need some agreement on what the "id" attribute should
mean. Right now, I view this as an attribute that allows an element to
be a target for a href. This is true regardless of whether this
attribute is of type ID or NMNTOKEN. I'm not convinced that we need to
introduce xml:id and split the attribute into two. It complicates
implementation and confuses the author who would have to use two
distinct attributes as link/conref targets. It is one thing for a user
to expect xml:id if it is in fact an xml:id. It is another thing for a
user to look for a link/conref target and have to deal with something
that can be "xml:id" or "id".
Chris
Paul Grosso wrote:
1. xml:id doesn't buy us anything. The point is that I
expect users will be
getting used to xml:id over time and will be
surprised it doesn't work
in DITA to specify an id.
2. If some attributes are really IDs and others aren't,
then one might argue
that giving them
different names seems obvious and less confusing than
using the same name for things that
are different.
paul
A couple of things come to mind:
- What does xml:id buy us? I would expect
anything that processes DITA to be DITA-aware, so the need for an
explicit xml:id is not clear to me.
- In DITA, topic level ids are of type ID, but content ids are
not. The latter are explicitly not of type ID to allow duplication. Are
we going to split the id names? Sounds like a pain.
Chris
Paul Grosso wrote:
- Issue 31 -- Side-by-side implementation of xml:id?
- I couldn't capture the discussion.
- Let's keep it on the list for 1.1 and keep
discussing it.
Here's my explanation/discussion.
The W3C is developing a Recommendation that defines
the (reserved) attribute named xml:id to be of type "id"
even in the absence of any DTD or other schema. The
idea is to make it easier to have ids in well-formed
XML documents (even if there is no schema).
Since DITA documents will generally be processed under
the influence of a schema, the use of xml:id may not be
needed. However, if the use of xml:id becomes widespread
practice, in several years, users may expect to be able
to use xml:id to put an id on elements. Furthermore,
there may be certain processes where DITA content is
processed in the absence of any schema, and using xml:id
could be useful in this situation.
It is a validity error in XML for an element to have
more than one attribute on it whose type is "id".
The xml:id spec makes it an error to declare xml:id
to have any type other than "id". Therefore, if we
were to add xml:id as an attribute on topic, we would
have to change the type of the existing id attribute
to be NMTOKEN (that is, we could not leave it as ID).
Michael didn't think that changing the type of the
existing id attribute to NMTOKEN would be much of
a problem. I defer to him in this determination.
If we changed id to NMTOKEN and added xml:id to the
topic element type declaration in DITA 1.1, we might
have a fairly smooth transition path to using xml:id.
If we think we'll ever want to transition to xml:id,
I think doing it sooner (i.e., in DITA 1.1) is better.
paul
|