Subject: Re: service URLs and naming authorities

From: James Kempf <[email-masked]>
Date: Wed, 17 Feb 1999 09:00:54 -0800 (PST)

s.
>
>in short, is it possible for both the abstract and concrete components
>of a service type name to have naming authorities?  if so, can they be
>different?
>

No. If you look at the service URL grammer in service-scheme-14, only
the abstract type name has a naming authority. The second component
of the name, called "url-scheme" in the grammer, has no naming
authority. The idea here is that the portion after the first
colon should be, in and of itself, a URL from a valid scheme.
Since generic URL schemes don't have naming authorities, this
would rule out a naming authority on the second component.

>a second problem: the service: URL ABNF grammar in service-scheme-14
>section 2.1 also seems to indicate that a service-type cannot consist
>solely of an abstract-type.
>
>the relevant portion of the grammar is
>
>  service-type    =   abstract-type ":" url-scheme / concrete-type
>  abstract-type   =   type-name [ "." naming-auth ]
>  concrete-type   =   protocol [ "." naming-auth ]
> 
>

The terminology in the service-scheme-14 is somewhat confused about what 
is an abstract type and what is a concrete type. The grammer implies
that a concrete type has just the type name and optional naming
authority, and that an abstract type name is the first name in
a two component service type name.

The text uses the term "concrete type" to mean the two component service
type name itself.

I prefer the name "simple type" to refer to a one component type 
name like "service:lpr" and "concrete type" to refer to 
a two component type name like "service:printing:lpr". The
first component of a two component name is the abstract type, as in 
the grammer; "service:printing" in this example.

Given that clarification, there are only two ways to distinguish
a simple type name from an abstract type name;

1) Usage

2) A service type template.

In the first, if a two component service type name is advertised then
the first component is the abstract type. However, the very same
one component type name could also be advertised as a simple type.
This would allow someone to advertise a service URL with type
"service:printing" as well as a service URL with type "service:printing:lpr".
The protocol makes no distinction, so barring other considerations,
only usage differentiates.

However, a pair of service type templates specifying an abstract and
concerete type define a particular one component type name as an abstract type.
Following through on the example, if someone defines a service type
template for "service:printing" and for "service:printing:lpr", then
it is clear that "service:printing" is an abstract type. Furthermore,
the description of the service in the abstract type template should
clearly specify that this is an abstract type. The concrete type
inherits from the abstract type, as service-scheme-14 makes clear.

This does not prohibit a service from just advertising the abstract type
name (unless the DA or API choose to enforce template typing and prohibit it)
but it does clarify the relationship.

This is a somewhat longwinded answer, however the upshot is that whether
a particular service type name is an abstract type or a simple type
is primarily a matter of conventional usage and the definition of
a service type template. 

Is that of any help?

		jak

---

From: David Arnold <[email-masked]>
Date: Thu, 18 Feb 1999 08:20:12 +1000

-->"James" == James Kempf <[email-masked]> writes:

< much useful text >

  James> Is that of any help?

yes.  thanks for the clarifications, James.  i think that fixes my
type lookup problems.

just as a note, the grammar does not appear to define "protocol" (as
used in concrete-type).  i'm assuming it's a resname with some
usage restrictions?

d