Re: [dita] RE: Issue 12007 : Indirect reference/keyref proposal

["Eliot Kimber" <ekimber@reallysi.com>]

On 10/30/07 1:58 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote:

>> 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]".
> 
> I believe as much as anyone that anything we call a
> URI-reference has to conform to RFC 3896, but there is no
> reason that we can't say that the "datatype" for the href
> attribute is "URI-reference | key-reference" (and then
> define key-reference as needed) as long as there is an
> unambiguous syntactic way for processors to tell whether
> a given href value is a URI-reference or key-reference.

Yes, that's the only conclusion I can come to if using fragment identifiers
is also rejected.

>> 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.
> 
> I don't think this is going to fly.  I believe we'd have to
> write an RFC to register a new scheme, and I don't think that
> it would be approved given that new schemes are not generally
> given out for such things.  See for example what the
> "Architecture of the World Wide Web" document says about new
> schemes at: http://www.w3.org/TR/webarch/#URI-scheme .

I will certainly defer to your experience working directly with the TAG but
I didn't read that section to be as strong as a statement as you indicate. I
think a reasonable case could be made for a DITA-specific scheme for just
the reasons I said. But I'm not sure it would be worth the effort.

I do agree that we should not propose an unregistered scheme.

I note that the discussion of fragment identifiers does seem to be expansive
enough to accommodate the notion that keyref fragment identifiers are
identifying fragments of the "virtual" document represented by the governing
map. From the same webarch document:

<longquote>
2.6. Fragment Identifiers

[...]

The fragment identifier component of a URI allows indirect identification of
a secondary resource by reference to a primary resource and additional
identifying information. The secondary resource may be some portion or
subset of the primary resource, some view on representations of the primary
resource, *or some other resource defined or described by those
representations.* The terms "primary resource" and "secondary resource" are
defined in section 3.5 of [URI]. {Emphasis mine}

The terms ³primary² and ³secondary² in this context do not limit the nature
of the resource‹they are not classes. In this context, primary and secondary
simply indicate that there is a relationship between the resources for the
purposes of one URI: the URI with a fragment identifier. *Any resource can
be identified as a secondary resource.* It might also be identified using a
URI without a fragment identifier, and a resource may be identified as a
secondary resource via multiple URIs. The purpose of these terms is to
enable discussion of the relationship between such resources, not to limit
the nature of a resource. {Emphasis mine}
</longquote>

You are of course correct that "[keyref]" won't work syntacticaly, but of
course we can find some other syntax that would both be valid within an URI
and not confusable with a bare topic ID.

Cheers,

E.
-- 
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.