OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] xml:id [was: MEETING MINUTES -- 19 Apr 2005 -- DITA TECHNICALCOMMITTEE]

I agree with Chris.

Making an id attribute have an ID type buys you some things, but costs you others; similarly with IDREF-type attributes.

But since changing the datatype doesn't change the function - only how the function is implemented - it should still be called id (or linkend etc).

And to add xml:id to the mix before anyone even asks for it seems a needless complication.


Christopher Wong wrote:
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".


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.

From: Christopher Wong [mailto:cwong@idiominc.com]
Sent: Friday, 06 May, 2005 10:57
To: Paul Grosso
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] xml:id [was: MEETING MINUTES -- 19 Apr 2005 -- DITA TECHNICAL COMMITTEE]

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.

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]