[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 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]