OASIS Darwin Information Typing Architecture (DITA) TC

Michael Priestley wrote:
> 
> This is in the language spec, right?

Yes.

> There's a consolidated topic on referencing in the architectural spec, 
> first topic under "Behaviors".

I see this now.

I would not have expected to find this information under a section 
titled "behaviors" since addressing syntax has nothing to do (directly) 
with behavior (that is, the way that one uses addressing or the syntax 
involved has nothing to do with the behavior that might be implied by 
the link that uses the address).

I think that perhaps the better title for this section is "DITA 
processing semantics"--"behavior" suggests, at least to me, behavior *of 
renditions* (that is, behavior as in "link behavior", which is about 
interaction) rather than behavior of *processors* which is what this 
section is mostly talking about.

In any case, I think this information should also be in the language 
spec, so that the language spec can stand on its own as a specification 
of the syntax.

Note that the discussion under behaviors isn't 100% accurate in it's use 
of the term "URI" in that it implies that the URI is everything *before* 
the fragement identifier when in fact a URI includes the fragment 
identifier.

Also, I didn't see it here and I haven't noticed it anywhere else, but 
the spec doesn't seem to say whether element IDs must be unique within 
the scope of their *immediate parent* topic or simply within the scope 
of some ancestor topic. I think the intent is that they are unique 
within the scope of their immediate parent but that isn't said 
explicitly and it should be.

For example, if I have nested topics, I might think that I can address 
elements within the nested topics by using the ancestor topic's topic ID.

Cheers,

E.

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com

"W. Eliot Kimber" <ekimber@innodata-isogen.com>
wrote on 01/26/2007 04:22:43 PM:


> I would not have expected to find this information under a section

> titled "behaviors" since addressing syntax has nothing to
do (directly)

> with behavior (that is, the way that one uses addressing or the syntax

> involved has nothing to do with the behavior that might be implied
by

> the link that uses the address).

>

> I think that perhaps the better title for this section is "DITA

> processing semantics"--"behavior" suggests, at least
to me, behavior *of

> renditions* (that is, behavior as in "link behavior", which
is about

> interaction) rather than behavior of *processors* which is what this

> section is mostly talking about.

Would "DITA processing" work?


>

> In any case, I think this information should also be in the language

> spec, so that the language spec can stand on its own as a specification

> of the syntax.

It may be possible to provide a more abbreviated form
and reference the spec for details.


> Note that the discussion under behaviors isn't 100% accurate in it's
use

> of the term "URI" in that it implies that the URI is everything
*before*

> the fragement identifier when in fact a URI includes the fragment

> identifier.

The description refers to the URI of the document
instance, so I believe the description is technically accurate as it stands.
If you're saying that the full identifier (including the DITA syntax for
a two-part fragment identifier) is also a URI, I was unaware of that -
we still need to delineate the exact syntax used by DITA, ie we can't just
say it's a URI because we have extra syntax requirements, but I'd be happy
to take suggestions on the rewording. 


>

> Also, I didn't see it here and I haven't noticed it anywhere else,
but

> the spec doesn't seem to say whether element IDs must be unique within

> the scope of their *immediate parent* topic or simply within the scope

> of some ancestor topic. I think the intent is that they are unique

> within the scope of their immediate parent but that isn't said

> explicitly and it should be.

OK, will clarify. Proposed change:

Because topic content is always contained within a
topic, the id attribute
for a topic content element must be unique only within
the one topic that
immediately contains it. 

Michael Priestley