Menu
▾
▴
Re: [Psidev-ms-dev] Relative URIs and RFC-2396
|
From: Angel P. <an...@ma...> - 2008-02-20 16:02:34
|
On Wed, Feb 20, 2008 at 10:33 AM, Matthew Chambers < mat...@va...> wrote: > Very good point Angel. This is a problem with the use of the id > attribute everywhere. Can Xlink specify the attribute name as something > other than "id" if, for example, we renamed the id attribute for each > type to something unique to that type? E.g. <spectrum > spectrumId="foo.1.1.1.dta" /> > to clarify when I say XLink I mean XLink + XPointer. These have a short-hand URI reference to an element with an attribute named "id" and is of the form of "<URL or URI base>#id_value". Also note that (i believe but have not dug too deeply into this) the data type of said attribute is not important, only the name of "id" for the shorthand syntax to work. The full Xpointer reference just piggy backs off of XPath expressions to navigate the DOM model. So for your suggestion the XLink/XPointer ref value would look like this from analysisXML: <analysisXML> ... <spectrum_reference xmllink:type="simple" xlink:href=" http://sbeams.org/exp/1/mzml/3.xml#pointer(spectrumId('foo.1.1.dta'))" /> ... or something like that. I don't have time to provide a proper working example. Also to note that I could use xpointer +xpath to get any element regardless of it having an id attribute. <spectrum_reference xmllink:type="simple" xlink:href=" http://sbeams.org/exp/1/mzml/3.xml#pointer(../spectrumId[3])" /> Again not a rigourous example, as the result of this XPATH is actually a set, but the point is that analysisXML will adapt to mzML and we should not worry about that aspect. -angel I know it's not pretty and it would go against the shift away from > redundant strings in attribute names, but it may be necessary in this > case. > > -Matt > > Angel Pizarro wrote: > > also note the the ID attribute instances must be unique across all > > attributes that are of type ID, regardless of containign element. In > > other words <foo id="1" /> and <bar id="1" /> would violate this if > > both attributes named "id" were of type xsd:ID > > > > -angel > > > > > > On Wed, Feb 20, 2008 at 9:40 AM, Angel Pizarro > > <an...@ma... <mailto:an...@ma...>> wrote: > > > > As I understand it: > > > > ID & IDREF are used for internal references in single documents. > > > > XLinks are used to reference within and across documents. > > > > analysisXML can use XLink to reference a spectra pretty easily if > > you use ID as the document-unique identifier type. > > > > -angel > > > > > > On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers > > <mat...@va... > > <mailto:mat...@va...>> wrote: > > > > Yes, xs:ID definitely works as a fragment identifier, it's > > what XHTML > > and XML use for the core "id" attribute. :) > > > > A cross-file reference is composed of a document identifier > > (not sure > > what form this can take, so I assume anyURI) and an optional > > fragment > > identifier: > > "file://foo.mzML#foo.1.1.1.dta" would reference the element with > > id="foo.1.1.1.dta" in foo.mzML > > > > -Matt > > > > > > Angel Pizarro wrote: > > > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian > > <rkj...@in... <mailto:rkj...@in...> > > > <mailto:rkj...@in... > > <mailto:rkj...@in...>>> wrote: > > > > > > Does the xs:ID constraint solve this problem? > > > > > > > > > maybe since I think we had agreed that mzML REFs are > > within-file only ? > > > > > > > > > -----Original Message----- > > > From: psi...@li... > > <mailto:psi...@li...> > > > <mailto:psi...@li... > > <mailto:psi...@li...>> > > > [mailto:psi...@li... > > <mailto:psi...@li...> > > > <mailto:psi...@li... > > <mailto:psi...@li...>>] On > > Behalf Of > > > Matt > > > Chambers > > > Sent: Tuesday, February 19, 2008 10:34 PM > > > To: Mass spectrometry standard development > > > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396 > > > > > > After a little more thought, absolute instances of > > xs:anyURI will not > > > always work as a fragment identifier. If a spectrum's id > > attribute was > > > xs:anyURI in file "foo.mzML": > > > <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a > > valid (absolute) > > > xs:anyURI --> > > > > > > And in something like pepXML or analysisXML: > > > <spectrumQuery > > spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" /> > > > <!-- not a valid xs:anyURI! --> > > > > > > Unless I'm missing something, using xs:anyURI for > > fragment identifiers > > > would actually make the schema less safe. Valid mzML ids > > would be > > > potentially unusable in an external URI unless > > URL-encoded, which > > > would > > > defeat the point of using xs:anyURI in the first place. > > > > > > -Matt > > > > > > > > > Randy Julian wrote: > > > > All we are trying to achieve with the anyURI is safety > > for use > > > within > > > a > > > > URI. Any xlink-safe way of doing this will work. So > > if xs:ID is > > > > supported better by the validating parsers, it would > > do what we > > > want. > > > > > > > > -----Original Message----- > > > > From: psi...@li... > > <mailto:psi...@li...> > > > <mailto:psi...@li... > > <mailto:psi...@li...>> > > > > [mailto:psi...@li... > > <mailto:psi...@li...> > > > <mailto:psi...@li... > > <mailto:psi...@li...>>] On > > Behalf Of > > > > Matthew Chambers > > > > Sent: Tuesday, February 19, 2008 4:25 PM > > > > To: Mass spectrometry standard development > > > > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396 > > > > > > > > You are right Randy, we were forgetting about relative > > URIs > > > which can > > > > simply refer to a resource's name with no path at all > > ("1" is > > > certainly > > > > a valid resource name). However, I think anyURI is > > still a bad idea > > > for > > > > any attribute which is not intended to be able to > > refer to something > > > in > > > > a remote location (e.g. not in the current file). The > > "id" attribute > > > in > > > > the XML namespace has type "xs:ID" which has semantics > > more > > > along the > > > > lines of what I think you want. If I understand the > > use case > > > correctly, > > > > it is desirable to be able to link to certain mzML > > elements from > > > > external documents with a URI, like: > > > > file://data_source.mzML#s555 > > > > This is an example absolute URI reference to a > > spectrum in a file at > > > > "data_source.mzML" where the spectrum's id attribute > > is "s555". It > > > > wouldn't make sense for the id itself to be a URI, > > although the > > > > reference to it can (and should) be. > > > > > > > > So: > > > > 1) for id attributes which can be referred to > > externally or > > > internally, > > > > use the type "xs:ID" > > > > 2) for references to external or internal resources by > > their id > > > > attribute, use the type "xs:anyURI" > > > > > > > > This would have the problem of the Xerxes C parser not > > validating > > > > relative URIs correctly, but that seems to be wrong on > > their > > > part. :/ > > > > Anyway, users of Xerxes C can turn off the validation > > feature to > > > work > > > > around it. > > > > > > > > Also, Ref attributes in mzML could use anyURI for > > consistency > > > reasons > > > > even though we don't currently know of a use case > > where such > > > references > > > > would be made to an external file. > > > > > > > > -Matt > > > > > > > > > > > > Randy Julian wrote: > > > > > > > >> Per our conversation today, the relevant > > specification is RFC-2396: > > > >> > > > >> http://www.ietf.org/rfc/rfc2396.txt > > > >> > > > >> Section 5 talks about relative URIs. They do not need > to > > > include the > > > >> protocol and their syntax would include all integers: > > > >> > > > >> The syntax for relative URI takes advantage of the > > <hier_part> > > > syntax > > > >> of <absoluteURI> (Section 3) in order to express a > > reference > > > that > > > >> > > > > is > > > > > > > >> relative to the namespace of another hierarchical > URI. > > > >> > > > >> relativeURI = ( net_path | abs_path | > > rel_path ) [ "?" > > > query > > > ] > > > >> > > > >> A relative reference beginning with two slash > > characters is > > > termed > > > >> > > > > a > > > > > > > >> network-path reference, as defined by <net_path> > > in Section 3. > > > >> > > > > Such > > > > > > > >> references are rarely used. > > > >> > > > >> A relative reference beginning with a single slash > > character is > > > >> termed an absolute-path reference, as defined by > > <abs_path> in > > > >> Section 3. > > > >> > > > >> A relative reference that does not begin with a > > scheme name or a > > > >> slash character is termed a relative-path reference. > > > >> > > > >> rel_path = rel_segment [ abs_path ] > > > >> > > > >> rel_segment = 1*( unreserved | escaped | ";" > > | "@" | "&" | > > > "=" > > > >> > > > > | "+" | "$" | "," ) > > > > > > > >> That means that you don't need the net_path part or the > > > abs_path part > > > > > > >> but can use the rel_path part alone. The rel_path > > part can have > > > only > > > >> the rel_segment part which is required to have one or > > more > > > unreserved > > > > > > >> characters (includes all the integers) and/or any of > > the above > > > special > > > >> > > > > > > > > > > > >> characters or escaped characters. > > > >> > > > >> The point of using it in mzML for IDs is that you can > > be assured of > > > it > > > >> > > > > > > > > > > > >> being a valid relative path when extended by all the > > other > > > components > > > > > > >> needed to navigate to a referenced document > > (protocol, absolute > > > path, > > > > > > >> etc.). > > > >> > > > >> We can achieve this by convention by saying in the > > mzML spec > > > doc (and > > > > > > >> possibly putting the required pattern in the schema), > > that the > > > string > > > > > > >> for ID must conform to RFC-2396. > > > >> > > > >> Randy > > > >> > > > >> Randall K Julian, Jr. Ph.D. > > > >> President > > > >> Indigo BioSystems, Inc. > > > >> (317) 536-2736 x101 > > > >> (317) 306-5447 mobile > > > >> > > > >> www.indigobio.com <http://www.indigobio.com> > > <http://www.indigobio.com> > > > <http://www.indigobio.com/> > > > >> > > > > > > > > > > v > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > <mailto:Psi...@li...> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > > > > > > > > -- > > Angel Pizarro > > Director, ITMAT Bioinformatics Facility > > 806 Biological Research Building > > 421 Curie Blvd. > > Philadelphia, PA 19104-6160 > > 215-573-3736 > > > > > > > > > > -- > > Angel Pizarro > > Director, ITMAT Bioinformatics Facility > > 806 Biological Research Building > > 421 Curie Blvd. > > Philadelphia, PA 19104-6160 > > 215-573-3736 > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > -- Angel Pizarro Director, ITMAT Bioinformatics Facility 806 Biological Research Building 421 Curie Blvd. Philadelphia, PA 19104-6160 215-573-3736 |
