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] RE: Issue 12007 : Indirect reference/keyref proposal

On 10/30/07 12:57 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> The draw back to these alternatives is that an href value that
> contains a key reference of this sort would not be a valid URI. An href
> value does not have to be a valid URI, but in DITA today all of the href
> values are in fact valid URIs.  We could change this, but we aren't sure
> if it will cause implementers serious problems or not. Feedback from
> real implementers would be most welcome.

I was going to say that in fact href= values must be URIs but a reread of
the language spec just says that *external* references must be URLs (not
URIs) but doesn't explicitly constrain value of internal (DITA-based data)
references (although I think that is an oversight on the part of the spec
writers rather than explicit intent that href= values not be URIs or URLs,
but I guess that would be for Michael to confirm or deny). I could swear
that somewhere in the spec it says that href= values must be URIs but I
couldn't find it just now.

That language should have been corrected before publication (I know I
submitted some comments on the details of how the specs discussed URIs and
URLs in general but I don't know that I ever followed up on those comments).

In any case, Jeff is correct that the spec as written does not require href=
values to be URIs.

That means that, contrary to my earlier assertions, a non-URI syntax like
"[keyvalue]" (unescaped square brackets are not allowed in URI path
components) is valid per the spec as written.

My argument against using a non-URI syntax is that any processor that
assumes href= values are URIs and thus tries to directly construct a URI
from href= values will throw an exception when given something like

But since the current spec does *entirely* justify that implementation
approach I suppose I can't claim that the use of non-URI syntax would be
wrong on its face.

However, I still think it would be better all around to require href= values
to be URIs (and thus use a DITA-specific scheme for key references) than
allow values that are completely DITA-specific.

The use of a scheme, for example, would plug nicely into existing standard
URI processing frameworks for integrating new scheme handlers (a standard
part of Java, for example). The alternative would require non-standard,
non-URI-based, DITA-specific processing for key references.

I think that the definition of a DITA-specific scheme in this case is fairly
well justified because DITA, as a generic, implementation-independent
specification, defines a "virtual" processing environment that legitimately
has its own rules for how things in that universe are addressed. That is,
DITA is essentially saying that there is a universe of DITA topics that can
be addressed in a standard way regardless of the details of where or how
they are stored. This is what a URI scheme means, I think.

The caution against creating schemes seems to be more about specific content
management systems defining schemes that are specific *to that product* when
existing schemes would work just fine. That is, any CMS system can easily
expose all its resources and semantics as normal HTTP URLs just
fine--creating a new scheme would just be a convenience for the
implementors. That is, defining a new scheme when an existing scheme
(meaning HTTP, since that's the only generally-implemented scheme) would
work is no a good idea. But...

By contrast, DITA has no way to define an *implementation independent* way
of doing key references within URI syntax constraints without defining a new
scheme. That is, there is no way (at least that we can think of) to use HTTP
URL syntax to unambiguously represent a key reference that is not seriously
confusing or just plain a non-starter.

I think it is just that sort of *standard* definition for which schemes were

The only other alternative to the above options is to always have the keyref
be part of the fragment identifier, e.g.:


This is syntactically fine but has the problem that some people might expect
that the fragment identifier in this case is addressing something relative
to the current document when in fact it means "relative to the current map"
where "current map" is defined by the current processing context.

I personally think this would be a good solution as I don't think it
inconsistent with the general definition of "fragement identifier" as I read
it in the URI spec. But I recognize that not everyone would be so accepting.



W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770

Sent using the Microsoft Entourage 2004 for Mac Test Drive.

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