Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier semantics' ...)
From: [email-masked] (Mark Nottingham)
Date: Mon, 23 Sep 2002 14:50:26 -0700

[ trimmed distribution ]

my .02 -

> so, apart from the minor fixes, does anybody have an opinion about the
> prantheses vs. equals syntax issue?

Equals syntax is more URI-ish; it's easier to write a parser for
correctly, and it's more likely that current code can be reused.

> i also thought about adding a
> checksum facility (md5 or something along these lines), so that fragment
> identifiers could recognize a particular version of a resource. any
> opinions about this feature (it would be optional, so that applications
> would be allowed to ignore the checksum)?

The fragment identifier doesn't seem like a good place to put this
functionality, IMHO. If people want to version their docs, they should
have different URIs for them.

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Thu, 12 Sep 2002 22:34:51 +0200
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 6, 2002, 10:33:15 PM, Chris wrote:

CL> I thought the draft a little cautious regarding IRI although given the
CL> content of
CL> http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
CL> perhaps this is wise. I hope that
CL> http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
CL> gets republished soon.

The reason that -09 is expired is that the authorship changed. The
most current draft is thus draft-duerst-iri-01.txt "available at, for
example",

http://www.w3.org/International/2002/draft-duerst-iri-01.txt

-- 
 Chris                            mailto:[email-masked]

From: [email-masked] (MURATA Makoto)
Date: Sat, 07 Sep 2002 11:29:15 +0900
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

I have some questions about fragment identifiers.

When the media type is determined by negotiation, how can users 
specify fragment identifiers in advance?  I'm happy to see 
that the TAG is already considering this issue.

If fragment identifiers are interpreted by clients, why should 
they be standardized as part of URIs?  To me, they are not part 
of URIs or protocols, but they are instructions to clients.  In 
other words, why different applications for the same media type 
have to agree on fragment identifiers?

Cheers,

Makoto

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Fri, 6 Sep 2002 22:33:15 +0200
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, September 5, 2002, 9:27:35 PM, David wrote:

DH> -----BEGIN PGP SIGNED MESSAGE-----

DH> Dan Kohn wrote:
>> It would also be worth noting and/or commenting on this draft:
>> 
>> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

DH> Yuch. This is overcomplicated and not sufficiently useful to justify the
DH> risk of security flaws in parsing regular expressions. There's a good
DH> case for supporting a simple "#<line-number>" syntax for text/plain, but
DH> nothing more IMHO.

Depends what you want it for. For Ted Nelson-style standoff markup,
you would need character addressing and ranges, too. Matching on text
patterns is handy to make more robust links if the document is being
edited (and would be even more handy if combinations, such as "the
seven lines after 'Non-ASCII Characters in Regular Expressions'" were
possible) (although, there are still problems if a revision takes that
to eight lines, or a 'page break' intervenes as here).

The draft does usefully distinguish between characters and bytes, and
counts the former, minus (normalized) line endings,and wisely stays
away from attempting to count words, sentences, or paragraphs (though
the latter would be tractable).

There are some unresolved questions of detail - what does
#char(6) point to in the text file containing "Hi World" encoded in
UTF-16, for example - "o" or "W" (is the BOM two characters, or a
thing before the first character).

It also distinguishes between point and range references, which is
vital (particularly since fragments in HTML and, less commonly, in XML
are often incorrectly assumed to be point references.

It might be worth mentioning that the encoding of the text in a match
string might well be different to the encoding of the text document
containing the string to be matched.

The pointer to the (recently expired but still there)
http://www.ietf.org/internet-drafts/draft-borden-frag-00
was valuable.

text-scheme   =  ( char-scheme / line-scheme / regex-scheme )
should presumably be
text-scheme   =  ( char-scheme / line-scheme / match-scheme )

I thought the draft a little cautious regarding IRI although given the
content of
http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
perhaps this is wise. I hope that
http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
gets republished soon.

For non-normative reference to BRE, the following might be useful:

 An Introduction to Posix Regexps
 http://www.regexps.com/src/docs.d/hackerlab/html/introduction-to-regexps.html

 Regular Expressions
 http://www.opengroup.org/onlinepubs/7908799/xbd/re.html

 The latter includes a BRE grammar.

-- 
 Chris                            mailto:[email-masked]

From: [email-masked] (David Hopwood)
Date: Thu, 05 Sep 2002 20:22:48 +0000
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier semantics' ...)
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Dan Kohn wrote:
> It would also be worth noting and/or commenting on this draft:
> 
> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

Yuch. This is overcomplicated and not sufficiently useful to justify the
risk of security flaws in parsing regular expressions. There's a good
case for supporting a simple "#<line-number>" syntax for text/plain, but
nothing more IMHO.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (Dan Kohn)
Date: Thu, 5 Sep 2002 09:43:24 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <[email-masked]>

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:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600> =20

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

-----Original Message-----
From: Chris Lilley [mailto:[email-masked]]=20
Sent: Thursday, September 05, 2002 06:44
To: [email-masked]; Larry Masinter
Cc: [email-masked]; [email-masked]
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

--=20
 Chris                            mailto:[email-masked]

_______________________________________________
Ietf-types mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-types

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Thu, 5 Sep 2002 15:43:37 +0200
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

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:[email-masked]

From: [email-masked] (Mark Nottingham)
Date: Wed, 4 Sep 2002 09:37:49 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <01a201c25431$6a25d470$6f0ba8c0@mnotlaptop>

+1

Regarding "good policy", I would encourage people to make fragment
identifiers, where possible, refer to 'anchor' style identifiers (i.e.,
using an extensibility mechanism like the 'id' attribute in XML, 'name' in
HTML, and so forth) rather than into the syntax and structure of the
format (as XPointer allows, through use of XPath). Doing so increases the
chance that a fragment identifier could be valid and useful across
multiple formats.

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 04, 2002 8:57 AM
Subject: Including 'fragment identifier semantics' in MIME media type
registration?

>
> The URI specification notes that the interpretation
> of a fragment identifier (the part of a URI reference
> after a '#') depends on the media type.
>
> However, the template for media type registration
> doesn't have a place to document the meaning of
> fragment identifiers within the media type.
>
> Originally, fragment identifiers were only used within
> HTML documents, so the point was somewhat moot. However,
> now there are several specifications -- mainly from
> the W3C -- that use fragment identifiers more explicitly,
> as well as proposals for changing or adding semantics
> for fragment identifiers for existing media types
> (such as a recent proposal for a fragment identifier
> for plain text.)
>
> Should the registration form for media types include
> a statement about the semantics of fragment identifiers
> for that media type?
>
> Is there a consistent policy or design for 'good'
> fragment identifier use?
>
> Larry
> --
> http://larry.masinter.net
>
>

From: [email-masked] (Larry Masinter)
Date: Wed, 4 Sep 2002 08:57:01 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <000901c2542b$b58d04c0$6ace8642@masinter>

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

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

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

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

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

Larry
-- 
http://larry.masinter.net

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:34 2006
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier    semantics' ...)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <050101c2634b$3c241590$ea00200a@mnotlaptop>

[ trimmed distribution ]

my .02 -

> so, apart from the minor fixes, does anybody have an opinion about the
> prantheses vs. equals syntax issue?

Equals syntax is more URI-ish; it's easier to write a parser for
correctly, and it's more likely that current code can be reused.

> i also thought about adding a
> checksum facility (md5 or something along these lines), so that fragment
> identifiers could recognize a particular version of a resource. any
> opinions about this feature (it would be optional, so that applications
> would be allowed to ignore the checksum)?

The fragment identifier doesn't seem like a good place to put this
functionality, IMHO. If people want to version their docs, they should
have different URIs for them.

From: [email-masked] (Mark Nottingham)
Date: Mon, 23 Sep 2002 14:50:26 -0700
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier    semantics' ...)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <050101c2634b$3c241590$ea00200a@mnotlaptop>

[ trimmed distribution ]

my .02 -

> so, apart from the minor fixes, does anybody have an opinion about the
> prantheses vs. equals syntax issue?

Equals syntax is more URI-ish; it's easier to write a parser for
correctly, and it's more likely that current code can be reused.

> i also thought about adding a
> checksum facility (md5 or something along these lines), so that fragment
> identifiers could recognize a particular version of a resource. any
> opinions about this feature (it would be optional, so that applications
> would be allowed to ignore the checksum)?

The fragment identifier doesn't seem like a good place to put this
functionality, IMHO. If people want to version their docs, they should
have different URIs for them.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:34 2006
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 6, 2002, 10:33:15 PM, Chris wrote:

CL> I thought the draft a little cautious regarding IRI although given the
CL> content of
CL> http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
CL> perhaps this is wise. I hope that
CL> http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
CL> gets republished soon.

The reason that -09 is expired is that the authorship changed. The
most current draft is thus draft-duerst-iri-01.txt "available at, for
example",

http://www.w3.org/International/2002/draft-duerst-iri-01.txt

-- 
 Chris                            mailto:[email-masked]

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Thu, 12 Sep 2002 22:34:51 +0200
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 6, 2002, 10:33:15 PM, Chris wrote:

CL> I thought the draft a little cautious regarding IRI although given the
CL> content of
CL> http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
CL> perhaps this is wise. I hope that
CL> http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
CL> gets republished soon.

The reason that -09 is expired is that the authorship changed. The
most current draft is thus draft-duerst-iri-01.txt "available at, for
example",

http://www.w3.org/International/2002/draft-duerst-iri-01.txt

-- 
 Chris                            mailto:[email-masked]

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:34 2006
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

I have some questions about fragment identifiers.

When the media type is determined by negotiation, how can users 
specify fragment identifiers in advance?  I'm happy to see 
that the TAG is already considering this issue.

If fragment identifiers are interpreted by clients, why should 
they be standardized as part of URIs?  To me, they are not part 
of URIs or protocols, but they are instructions to clients.  In 
other words, why different applications for the same media type 
have to agree on fragment identifiers?

Cheers,

Makoto

From: [email-masked] (MURATA Makoto)
Date: Sat, 07 Sep 2002 11:29:15 +0900
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

I have some questions about fragment identifiers.

When the media type is determined by negotiation, how can users 
specify fragment identifiers in advance?  I'm happy to see 
that the TAG is already considering this issue.

If fragment identifiers are interpreted by clients, why should 
they be standardized as part of URIs?  To me, they are not part 
of URIs or protocols, but they are instructions to clients.  In 
other words, why different applications for the same media type 
have to agree on fragment identifiers?

Cheers,

Makoto

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:34 2006
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, September 5, 2002, 9:27:35 PM, David wrote:

DH> -----BEGIN PGP SIGNED MESSAGE-----

DH> Dan Kohn wrote:
>> It would also be worth noting and/or commenting on this draft:
>> 
>> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

DH> Yuch. This is overcomplicated and not sufficiently useful to justify the
DH> risk of security flaws in parsing regular expressions. There's a good
DH> case for supporting a simple "#<line-number>" syntax for text/plain, but
DH> nothing more IMHO.

Depends what you want it for. For Ted Nelson-style standoff markup,
you would need character addressing and ranges, too. Matching on text
patterns is handy to make more robust links if the document is being
edited (and would be even more handy if combinations, such as "the
seven lines after 'Non-ASCII Characters in Regular Expressions'" were
possible) (although, there are still problems if a revision takes that
to eight lines, or a 'page break' intervenes as here).

The draft does usefully distinguish between characters and bytes, and
counts the former, minus (normalized) line endings,and wisely stays
away from attempting to count words, sentences, or paragraphs (though
the latter would be tractable).

There are some unresolved questions of detail - what does
#char(6) point to in the text file containing "Hi World" encoded in
UTF-16, for example - "o" or "W" (is the BOM two characters, or a
thing before the first character).

It also distinguishes between point and range references, which is
vital (particularly since fragments in HTML and, less commonly, in XML
are often incorrectly assumed to be point references.

It might be worth mentioning that the encoding of the text in a match
string might well be different to the encoding of the text document
containing the string to be matched.

The pointer to the (recently expired but still there)
http://www.ietf.org/internet-drafts/draft-borden-frag-00
was valuable.

text-scheme   =  ( char-scheme / line-scheme / regex-scheme )
should presumably be
text-scheme   =  ( char-scheme / line-scheme / match-scheme )

I thought the draft a little cautious regarding IRI although given the
content of
http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
perhaps this is wise. I hope that
http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
gets republished soon.

For non-normative reference to BRE, the following might be useful:

 An Introduction to Posix Regexps
 http://www.regexps.com/src/docs.d/hackerlab/html/introduction-to-regexps.html

 Regular Expressions
 http://www.opengroup.org/onlinepubs/7908799/xbd/re.html

 The latter includes a BRE grammar.

-- 
 Chris                            mailto:[email-masked]

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Fri, 6 Sep 2002 22:33:15 +0200
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier   semantics' ...)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, September 5, 2002, 9:27:35 PM, David wrote:

DH> -----BEGIN PGP SIGNED MESSAGE-----

DH> Dan Kohn wrote:
>> It would also be worth noting and/or commenting on this draft:
>> 
>> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

DH> Yuch. This is overcomplicated and not sufficiently useful to justify the
DH> risk of security flaws in parsing regular expressions. There's a good
DH> case for supporting a simple "#<line-number>" syntax for text/plain, but
DH> nothing more IMHO.

Depends what you want it for. For Ted Nelson-style standoff markup,
you would need character addressing and ranges, too. Matching on text
patterns is handy to make more robust links if the document is being
edited (and would be even more handy if combinations, such as "the
seven lines after 'Non-ASCII Characters in Regular Expressions'" were
possible) (although, there are still problems if a revision takes that
to eight lines, or a 'page break' intervenes as here).

The draft does usefully distinguish between characters and bytes, and
counts the former, minus (normalized) line endings,and wisely stays
away from attempting to count words, sentences, or paragraphs (though
the latter would be tractable).

There are some unresolved questions of detail - what does
#char(6) point to in the text file containing "Hi World" encoded in
UTF-16, for example - "o" or "W" (is the BOM two characters, or a
thing before the first character).

It also distinguishes between point and range references, which is
vital (particularly since fragments in HTML and, less commonly, in XML
are often incorrectly assumed to be point references.

It might be worth mentioning that the encoding of the text in a match
string might well be different to the encoding of the text document
containing the string to be matched.

The pointer to the (recently expired but still there)
http://www.ietf.org/internet-drafts/draft-borden-frag-00
was valuable.

text-scheme   =  ( char-scheme / line-scheme / regex-scheme )
should presumably be
text-scheme   =  ( char-scheme / line-scheme / match-scheme )

I thought the draft a little cautious regarding IRI although given the
content of
http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-09.txt
perhaps this is wise. I hope that
http://www.w3.org/International/2001/draft-masinter-url-i18n-08.txt
gets republished soon.

For non-normative reference to BRE, the following might be useful:

 An Introduction to Posix Regexps
 http://www.regexps.com/src/docs.d/hackerlab/html/introduction-to-regexps.html

 Regular Expressions
 http://www.opengroup.org/onlinepubs/7908799/xbd/re.html

 The latter includes a BRE grammar.

-- 
 Chris                            mailto:[email-masked]

From: david.hopwood at zetnet.co.uk (David Hopwood)
Date: Tue Jan  3 16:22:34 2006
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier  semantics' ...)
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Dan Kohn wrote:
> It would also be worth noting and/or commenting on this draft:
> 
> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

Yuch. This is overcomplicated and not sufficiently useful to justify the
risk of security flaws in parsing regular expressions. There's a good
case for supporting a simple "#<line-number>" syntax for text/plain, but
nothing more IMHO.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Thu, 05 Sep 2002 20:22:48 +0000
Subject: draft-wilde-text-fragment-01 (was: Including 'fragment identifier semantics' ...)
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Dan Kohn wrote:
> It would also be worth noting and/or commenting on this draft:
> 
> http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-01

Yuch. This is overcomplicated and not sufficiently useful to justify the
risk of security flaws in parsing regular expressions. There's a good
case for supporting a simple "#<line-number>" syntax for text/plain, but
nothing more IMHO.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: dan at dankohn.com (Dan Kohn)
Date: Tue Jan  3 16:22:33 2006
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <[email-masked]>

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:[email-masked]>
<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:[email-masked]] 
Sent: Thursday, September 05, 2002 06:44
To: [email-masked]; Larry Masinter
Cc: [email-masked]; [email-masked]
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:[email-masked]

_______________________________________________
Ietf-types mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-types

From: [email-masked] (Dan Kohn)
Date: Thu, 5 Sep 2002 09:43:24 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <[email-masked]>

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:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600> =20

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

-----Original Message-----
From: Chris Lilley [mailto:[email-masked]]=20
Sent: Thursday, September 05, 2002 06:44
To: [email-masked]; Larry Masinter
Cc: [email-masked]; [email-masked]
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

--=20
 Chris                            mailto:[email-masked]

_______________________________________________
Ietf-types mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-types

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:33 2006
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

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:[email-masked]

From: Chris Lilley <[email-masked]> (Chris Lilley)
Date: Thu, 5 Sep 2002 15:43:37 +0200
Subject: Including 'fragment identifier semantics' in MIME media type registration?
In-Reply-To: <000901c2542b$b58d04c0$6ace8642@masinter>
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <[email-masked]>

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:[email-masked]

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:33 2006
Subject: Including 'fragment identifier semantics' in MIME media type registration?
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <01a201c25431$6a25d470$6f0ba8c0@mnotlaptop>

+1

Regarding "good policy", I would encourage people to make fragment
identifiers, where possible, refer to 'anchor' style identifiers (i.e.,
using an extensibility mechanism like the 'id' attribute in XML, 'name' in
HTML, and so forth) rather than into the syntax and structure of the
format (as XPointer allows, through use of XPath). Doing so increases the
chance that a fragment identifier could be valid and useful across
multiple formats.

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 04, 2002 8:57 AM
Subject: Including 'fragment identifier semantics' in MIME media type
registration?

>
> The URI specification notes that the interpretation
> of a fragment identifier (the part of a URI reference
> after a '#') depends on the media type.
>
> However, the template for media type registration
> doesn't have a place to document the meaning of
> fragment identifiers within the media type.
>
> Originally, fragment identifiers were only used within
> HTML documents, so the point was somewhat moot. However,
> now there are several specifications -- mainly from
> the W3C -- that use fragment identifiers more explicitly,
> as well as proposals for changing or adding semantics
> for fragment identifiers for existing media types
> (such as a recent proposal for a fragment identifier
> for plain text.)
>
> Should the registration form for media types include
> a statement about the semantics of fragment identifiers
> for that media type?
>
> Is there a consistent policy or design for 'good'
> fragment identifier use?
>
> Larry
> --
> http://larry.masinter.net
>
>

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:33 2006
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <000901c2542b$b58d04c0$6ace8642@masinter>

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

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

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

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

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

Larry
-- 
http://larry.masinter.net

From: [email-masked] (Mark Nottingham)
Date: Wed, 4 Sep 2002 09:37:49 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
References: <000901c2542b$b58d04c0$6ace8642@masinter>
Message-ID: <01a201c25431$6a25d470$6f0ba8c0@mnotlaptop>

+1

Regarding "good policy", I would encourage people to make fragment
identifiers, where possible, refer to 'anchor' style identifiers (i.e.,
using an extensibility mechanism like the 'id' attribute in XML, 'name' in
HTML, and so forth) rather than into the syntax and structure of the
format (as XPointer allows, through use of XPath). Doing so increases the
chance that a fragment identifier could be valid and useful across
multiple formats.

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 04, 2002 8:57 AM
Subject: Including 'fragment identifier semantics' in MIME media type
registration?

>
> The URI specification notes that the interpretation
> of a fragment identifier (the part of a URI reference
> after a '#') depends on the media type.
>
> However, the template for media type registration
> doesn't have a place to document the meaning of
> fragment identifiers within the media type.
>
> Originally, fragment identifiers were only used within
> HTML documents, so the point was somewhat moot. However,
> now there are several specifications -- mainly from
> the W3C -- that use fragment identifiers more explicitly,
> as well as proposals for changing or adding semantics
> for fragment identifiers for existing media types
> (such as a recent proposal for a fragment identifier
> for plain text.)
>
> Should the registration form for media types include
> a statement about the semantics of fragment identifiers
> for that media type?
>
> Is there a consistent policy or design for 'good'
> fragment identifier use?
>
> Larry
> --
> http://larry.masinter.net
>
>

From: [email-masked] (Larry Masinter)
Date: Wed, 4 Sep 2002 08:57:01 -0700
Subject: Including 'fragment identifier semantics' in MIME media type registration?
Message-ID: <000901c2542b$b58d04c0$6ace8642@masinter>

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

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

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

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

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

Larry
-- 
http://larry.masinter.net