Hi Daniel, Daniel Hartwig <[email protected]> skribis:
> On 9 November 2012 04:10, Ludovic Courtès <[email protected]> wrote: >>> * TODO build-uri validation is broken/less strict and will now pass >>> relative-refs, so maybe introduce build-uri-reference instead >> >> Yes. Should uri-reference be a disjoint type, then? > > It needn't be, as long as there are predicates to distinguish. > (Actually, since <uri> is internal, maybe we should only expose the > new predicates, and keep “uri?” internal also). I’m fine with keeping <uri> internal, but ‘uri?’ is public and must remain so. Anyway, I think it’s fine if the documentation makes it clear whether functions expect absolute or relative URIs. WDYT? > The build-uri validation works on the values before the <uri> object > is constructed, so I was just thinking of a separate build method with > different, less strict validation. > > We just have to think of <uri> and uri? as guile implementation > details, not RFC. Another option, is to rename <uri> to > <uri-reference>. Then uri? can mean the same as absolute-uri? (as per > the RFC). Out current URI objects are actually absolute URI references, right? In that case, we’ll indeed have to make ‘uri?’ synonymous with ‘absolute-uri?’, for backward compatibility. >>> @@ -1729,7 +1736,7 @@ treated specially, and is just returned as a plain >>> string." >>> >>> ;; Referer = ( absoluteURI | relativeURI ) >>> ;; >>> -(declare-uri-header! "Referer") >>> +(declare-uri-reference-header! "Referer") >> >> Should actually be “Referrer”, no? > > This is the actual spelling used in the RFC. Ouch. >> Eventually, we’ll need docstrings, and updated documentation. > > Yes. I lazily left that until the other parts are finalized. Let me > tackle the remaining items over the next week. Yes, sure. Thanks! Ludo’.
