On 10/22/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 23/10/05 2:06 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
>
> > At the moment, I am really against writing spec language trying to
> > micromanage who sees pub:control information and who doesn't.  There  will 
> > be
> > some pub:control with a defined semantic (this is a draft).   There will be
> > other pub:control information that will be proprietary  to sixapart or 
> > google
> > or whoever.
> >
> I too don't want to get into micro-management of pub:control. I'd prefer one
> top level major-management rule for pub:control: visible only via APP.
>
> If you have other meta data you want to let float on downstream put it
> outside of pub:control.

If we were to do that we would remove the need for pub:control because
if the implementor has a need for "control" metadata and wants it
public it will have to put outside of pub:control. In the example of
our blog controls extension, vendors might want a lot of that
information to be visible outside of APP as well and that would only
create a mess. I think that Tim's point is to not give people the
option of inside vs. outside, but instead let the vendors choose what
will they make visible outside of APP. At least we will have a central
point for all control metadata, which I think it's good.

>
> > I agree that in most cases, this  would only be involved in editing 
> > operations
> > and would be effectively  one-way client->server.  I can think of all sorts 
> > of
> > applications  where you might want to pass this information back downstream 
> > to
> > a  client.  I can think of no scenarios where doing so would actually  harm
> > interoperability.
> >
>
> Perhaps a SHOULD requirement would suffice then? I'd be happy with SHOULD.
>
>
> > The implementors will sort it out. So why should we be trying to write rules
> > and define terms?
> >
>
> We didn't think through other contexts for 'self' and now we're stuck with a
> sub-optimal attribute value. Ditto 'alternate' for auto-discovery. Why
> should we be repeating these mistakes?
>
> e.
>
>

Reply via email to