Menu
▾
▴
psidev-ms-dev
|
From: Randy J. <rkj...@in...> - 2008-02-19 19:11:22
|
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/> NOTICE: This message may contain confidential or privileged information that is for the sole use of the intended recipient. Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. |
|
From: Matthew C. <mat...@va...> - 2008-02-19 21:25:37
|
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/>
>
> NOTICE: This message may contain confidential or privileged
> information that is for the sole use of the intended recipient. Any
> unauthorized review, use, disclosure, copying or distribution is
> strictly prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the
> original message.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Randy J. <rkj...@in...> - 2008-02-20 02:12:03
|
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...] 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/>
>
> NOTICE: This message may contain confidential or privileged
> information that is for the sole use of the intended recipient. Any
> unauthorized review, use, disclosure, copying or distribution is
> strictly prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the
> original message.
>
>
------------------------------------------------------------------------
>
>
------------------------------------------------------------------------
-
> 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
|
|
From: Matt C. <mat...@va...> - 2008-02-20 04:21:12
|
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...] 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/>
>>
>
|
|
From: Randy J. <rkj...@in...> - 2008-02-20 11:42:51
|
Does the xs:ID constraint solve this problem?
-----Original Message-----
From: 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...] 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/>
>>
>
------------------------------------------------------------------------
-
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
|
|
From: Angel P. <an...@ma...> - 2008-02-20 13:26:18
|
On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian <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...] 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...] 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/>
> >>
> >
>
>
> ------------------------------------------------------------------------
> -
> 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
|
|
From: Matt C. <mat...@va...> - 2008-02-20 14:21:06
|
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...>> 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...>] 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...>] 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/>
> >>
> >
>
> v
>
|
|
From: Angel P. <an...@ma...> - 2008-02-20 14:40:56
|
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...> 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...>> 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...>] 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...>] 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/>
> > >>
> > >
> >
> > 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...
> 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
|
|
From: Angel P. <an...@ma...> - 2008-02-20 14:45:24
|
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...>
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...> 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...>> 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...>] 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...>] 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/>
> > > >>
> > > >
> > >
> > > 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...
> > 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
|
|
From: Matthew C. <mat...@va...> - 2008-02-20 15:33:37
|
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" />
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
>
|
|
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 |
|
From: Fredrik L. <Fre...@im...> - 2008-02-21 11:24:18
|
Hi, I just tried this out, and it is no problem to have multiple attributes named 'id' for different elements which all are of type xs:ID. However, the content of all xs:ID type attributes need to be unique within the file, regardless of the name of the attributes. I changed the data type of the id attributes to xs:ID in a test schema, and changed the dataProcessingRef, sourceFileRef and some more to be of type xs:IDREF, where referencing should be within the file. The standard java schema validation really does check that the referenced ids are there and that the ids are unique etc. I agree that it would be good to change the data types of the ids of the referenceable elements, so that validation and referencing between files becomes easier. It is not a problem to assign unique IDs to files, samples and spectra. A simple solution is to have sourceFiles with ids SF1, SF2 etc and spectra as S1,S2...But anything can be used as the ids are unique. I've uploaded a new schema and the modified example file, in case anyone else wants to play with it. http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/Edited_mzML0.99.9_SNAPSHOT.xsd http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/FF_070504_MSMS_5B_edited.mzML I will remove the schema within a day or two to avoid mixing up with the real schema snapshots that Lennart are providing Some fields which I wonder about are the acquisition spectrumRef and sourceFileRefs. I guess referencing to external URIs could be allowed there. In that case: should the spectrumRef be put to the complete URI of the spectrum, or just the spectrum ID / scan number if raw data file? Maybe specrumRef should be type xs:String and sourceFileRef xs:anyURI. /Fredrik Matthew Chambers 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" /> > 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X