OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Issue: fragment identifier for href attribute

>I feel a bit uneasy about hard-coding a prohibition on fragment 
>identifiers.  This feels like it is trespassing on the domain on RFC 3023 
>and its successors. Couldn't we say something like this?

I do not oppose to your proposal.  However, I think that hard-coding a
prohibition on fragment identifieres is fine.

From the beginning, fragment identifiers are strange beasts.  URIs are
used to identify resources on the Web, and they play a critical role
on the WWW.  In particular, semantics of URIs do not depend on user
agents.  On the other hand, fragment identifiers are merely advice for
user agents and never used by HTTP.  Although these two play completely 
different roles, they are combined to form a URI reference.

Given URI references (which may be relative and may contain fragment
idenfiers), user agents create URIs (which are always absolute and
does not contain fragment idenfiers).  User agents then use the
created URIs to obtain resources on the Web.  After retrieving the
resources, user agents use fragment identifiers to take some action.

Are fragment identifiers useful for all types of recipients?  I think
that different recipients would like to have different types of
additional information (especially for text/xml and application/xml).
Then, why do we register fragment identifiers as part of media type
information?  I have no ideas.

As far as I know, only text/html has fragment identifiers.  Then, are
fragment identifiers specific to HTML browsers?  Probably, yes.

Going back to our issue "should we allow fragment identifiers", I see 
no reasons to allow them.  Our "user agents" are RELAX NG validators 
and they shouldn't be forced to support XPointer.  I do not want to 
allow the author of RFC 3023 to mess up RELAX NG.  :-)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC