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


> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Tuesday, 2007 October 30 13:41
> To: Ogden, Jeff; dita
> Subject: Re: [dita] RE: Issue 12007 : Indirect 
> reference/keyref proposal

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

> 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 think it is just that sort of *standard* definition for 
> which schemes were intended. 

I don't agree, and I don't think most of the W3C TAG would agree.

> The only other alternative to the above options is to always 
> have the keyref be part of the fragment identifier, e.g.:
> href="#[keyref]"

See section 2.2 Reserved Characters of RFC 3988 at

Square brackets are reserved in URIs which means they
should be percent-encoded.  I don't think we want to do this.

Besides, I see no advantage to this at all.

All we have to say is that an href value starting with a colon (:)
is interpreted as a keyref, otherwise it is interpreted as a URI.

Simple, unambiguous, allows us to define keyref any way we want,
and doesn't mess with RFCs we have no business messing with.


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