dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Discussion of conref href= value syntax
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "W. Eliot Kimber" <ekimber@innodata-isogen.com>
- Date: Sun, 4 Feb 2007 22:52:38 -0500
"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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]