# Re: options, not nesting?

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Oct 1993 14:47:25 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: Single protocol for UR*?"
- Previous message: Peter Deutsch: "Re: Thumbnail Sketch of the UR* Arena"
- Maybe in reply to: Larry Masinter: "options, not nesting?"
- Next in thread: Michael Mealling: "Re: options, not nesting?"
- Reply: Michael Mealling: "Re: options, not nesting?"

    Message-Id: <9310291847.AA06043@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Oct 1993 14:47:25 -0400

    In-Reply-To: Michael Mealling's message as of Oct 29, 10:49

    To: ccoprmm@oit.gatech.edu (Michael Mealling), terry@ora.com (Terry Allen)

    Subject: Re: options, not nesting?

[ Michael wrote: ]

. . .
> Then your parser has to know about EVERY possible URL protocol scheme. Plus
> it needs to be updated whenever you add a new scheme. If you just
> have URN: and URL: exist within a Template you end up with:
>
> URN:URN:IANA:bla
> URL:http://bla.com/bla
>
> That's acceptable but it makes URNs just look funny. I would prefer this:
>
> URN:IANA:bla
> URL:http://bla.com/bla

But then you'll have cases where your parse has to special
case URIs, and tack on the attribute name, but strip it
off for others. I'd say tokenize the LHS and ignore
repetitions when they occur.

> but I can live with the URN:URN: version...

I actually think it preferable.

- peterd

    --

- Next message: Peter Deutsch: "Re: Single protocol for UR*?"
- Previous message: Peter Deutsch: "Re: Thumbnail Sketch of the UR* Arena"
- Maybe in reply to: Larry Masinter: "options, not nesting?"
- Next in thread: Michael Mealling: "Re: options, not nesting?"
- Reply: Michael Mealling: "Re: options, not nesting?"