[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