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] Discussion of conref href= value syntax

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