[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue: fragment identifier for href attribute
James,
Good thoughts - I'm trying to distill this into even simpler shorter
statement.
Something like " RELAX NG does not prohibit the use of external referencing
to semantic definitions, in whole or part, however all such references
must return complete and meaningful RELAX syntax. Further the RELAX NG
parser is not responsible for any for the resolving, validation or
implementation
of any such external mechanisms. Preferred external mechanisms are those
that use approved standards as part of the XML syntax, either current or
future.".
Wordsmithing here!
Thanks, DW.
=======================================================
Message text written by James Clark
>
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?
- the meaning of the fragment identifier is determined by the registration
of the media type of the data returned by dereferencing the URI
- a RELAX NG schema must not use a fragment identifier for a URI if the
registration of the media type of the data returned by dereferencing the
URI does not specify the meaning of fragment identifiers for that media
type
- as of the time of writing, the registration of {text,application}/xml is
given by RFC 3023, which does not specify the meaning of fragment
identifiers (although it mentions XPointer)
In any case, it would be implementation dependent whether fragment
identifiers are supported, just as it is implementation dependent what URI
schemes are supported.
Basically, I feel that we should treat the URI reference as a black box
whose semantics are specified externally by the appropriate RFCs.
<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC