RE: Including 'fragment identifier semantics' in MIME media type registration?

Note that section 5 of RFC 3023 is probably due for an update based on
the W3C work you're considering.

http://www.ietf.org/rfc/rfc3023.txt

It would also be worth noting and/or commenting on this draft:

http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

          - dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>  

The mass of men lead lives of quiet desperation.  - Henry David Thoreau


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Thursday, September 05, 2002 06:44
To: www-tag@w3.org; Larry Masinter
Cc: uri@w3.org; ietf-types@iana.org
Subject: Re: Including 'fragment identifier semantics' in MIME media
type registration?


On Wednesday, September 4, 2002, 5:57:01 PM, Larry wrote:


LM> The URI specification notes that the interpretation
LM> of a fragment identifier (the part of a URI reference
LM> after a '#') depends on the media type.

LM> However, the template for media type registration
LM> doesn't have a place to document the meaning of
LM> fragment identifiers within the media type.

LM> Originally, fragment identifiers were only used within
LM> HTML documents, so the point was somewhat moot. However,
LM> now there are several specifications -- mainly from
LM> the W3C -- that use fragment identifiers more explicitly,
LM> as well as proposals for changing or adding semantics
LM> for fragment identifiers for existing media types
LM> (such as a recent proposal for a fragment identifier
LM> for plain text.)

LM> Should the registration form for media types include
LM> a statement about the semantics of fragment identifiers
LM> for that media type?

Yes, your well presented summary above clearly indicates that the
addition of such a section would be a desirable enhancement and close
the lgap between media types and the URI specification.

LM> Is there a consistent policy or design for 'good'
LM> fragment identifier use?

Previously I would have said yes; current discussions indicate that
there is some disagreement, but it is being actively discussed. I hope
that it will be possible, fairly soon, for the Architecture document
to specify 'best practice' and 'common idiom' and to clarify, in a way
that covers the majority of existing specifications, what fragment
identifiers do and how best to construct them and how they may be used
or their use may affect other stages of processing such as
presentation.

Currently, I believe that we may have to note that there are existing
exceptions that have an entirely different model. Although I am hoping
that by appropriate layering, we may be able to have a low level and
universally applicable "syntactic" processing that says "this
portion/fragment of the content has been linked to" and higher levels
('presentation', and 'semantic') that say, respectively what the
effect of traversing a link including a fragment has on presentation
and what effect it has on application semantics (hoping that covers
the RDF case).

There is some initial wording to that effect in the Architecture
document, though it needs further discussion.
http://www.w3.org/TR/2002/WD-webarch-20020830/#fragid

-- 
 Chris                            mailto:chris@w3.org

_______________________________________________
Ietf-types mailing list
Ietf-types@eikenes.alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-types

Received on Thursday, 5 September 2002 12:43:57 UTC