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


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