[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 "[keyvalue]". 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 intended. The only other alternative to the above options is to always have the keyref be part of the fragment identifier, e.g.: href="#[keyref]" 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. Cheers, Eliot -- W. Eliot Kimber Senior Solutions Architect Really Strategies, Inc. "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com Sent using the Microsoft Entourage 2004 for Mac Test Drive.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]