RE: Section 3.5. Passing fragment identifiers to other systems.

At 12:45 PM 2004-02-24, Williams, Stuart wrote:

>[Which implies the status-quo wrt the RFC2396bis draft - apologies for the
>disturbance].

Not at all.  doesn't represent status quo, only "status contemplated
in Roy's reply."  The status quo is still in a should-fix state.

RDF has established use patterns that require passing the #fragment
part to "other systems."

[conceptual analysis]

A resource may be considered to represent a view of the state of the universe.

In that view extraction, the fragment part must not affect the 'select'
semantics but may beneficially affect the 'present' semantics where the
'view' operation is factored into 'select' and 'present.'

So, the #fragment part MUST NOT affect the information contained in the
representation in response to a recovery request.  The User Agent MAY strip
the #fragment part and apply it post-recovery without loss of information.

But "MUST NOT" pass to "other systems" is unjustified and detrimental.
It should be fixed.  If we want to warn people off of abuse-encouraging
variants, we need to check out appropriate uses and draw the line
appropriately before we go there.

Has there been abuse?  Is there a public discussion of it somewhere?

In standard browsers, the fragment ID does affect the initial scroll and
focus properties of the view in the viewport.  In assistive middleware such
as the SWAP system, it would be appropriate for the system to add-in a
synthetic synopsis from the top of the page to the (#fragment-indicated)
point where reading starts as a third-party annotation.

http://www.ubaccess.com/solutions_SWAP.html

Al

> > Well, after thinking about this a bit, I've changed my mind.
> >
> > > I'm trying to understand why it is so important to state such a
> > > constraint wrt to retrieval and whether or not, maybe on the basis of
> > > minimal constraint, it was intentionally stated only for retrieval or
> > > whether it should be more universally applied.
> >
> > I think fragment identifiers are only defined for use with
> > retrieval, because the semantics of the fragment are
> > (supposed to be, at least)
>
>:-)
>
> > defined by the media type of the
> > retrieved result. With other operations, there is no clear media type.
>
>That makes sense.
>
>However, at least with HTTP other operations, PUT and POST,  do have
>potential to return response messages that carry representations with a
>media type - (in which case I guess one could argue that they are also a
>form of retrieval and hence covered - hmmm).
>
> > Using fragment identifiers for other purposes, with PUT,
> > POST, or any other operation, shouldn't be defined in the
> > IETF 'Standard'. Maybe someone wants to propose some other
> > semantics for fragment identifiers with operations other than
> > retrieval, but I don't think this document is the right place
> > to include those extensions.
>
>Yes... I think staying silent about non-retrival frag id semantics is likely
>best.
>
>[Which implies the status-quo wrt the RFC2396bis draft - apologies for the
>disturbance].
>
> > Larry
> > --
> > http://larry.masinter.net
>
>Thanks,
>
>Stuart

Received on Tuesday, 24 February 2004 17:08:09 UTC