Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Note - To bring this upto date old discussion topics have been moved here.

-- DaveMorris - 07 Dec 2007

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

The schema contains the following :

   <xsd:complexType name="PropertyDescriptionType">
      <xsd:annotation>
      ....
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="vs:BaseParam">
            <xsd:attribute name="key" type="xsd:string">
               <xsd:annotation>
               ....
               </xsd:annotation>
            </xsd:attribute>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

But the example contains the following :

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
  </key>

1. The schema has attribute key, but the example has element key attribute name.
2. The schema has complexType PropertyDescriptionType, but the example has xsi:type VOSpaceProperty

I suspect I might be looking at the wrong versions of things. Can you add the latest schema and example(s) as attachments to this page, so that we can track the changes.

-- DaveMorris - 13 Jul 2007

The schema contains the following :

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

-- DaveMorris - 13 Jul 2007

Votes

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Note - To bring this upto date old discussion topics have been moved here.

-- DaveMorris - 07 Dec 2007

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

The schema contains the following :

   <xsd:complexType name="PropertyDescriptionType">
      <xsd:annotation>
      ....
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="vs:BaseParam">
            <xsd:attribute name="key" type="xsd:string">
               <xsd:annotation>
               ....
               </xsd:annotation>
            </xsd:attribute>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

But the example contains the following :

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
  </key>

1. The schema has attribute key, but the example has element key attribute name.
2. The schema has complexType PropertyDescriptionType, but the example has xsi:type VOSpaceProperty

I suspect I might be looking at the wrong versions of things. Can you add the latest schema and example(s) as attachments to this page, so that we can track the changes.

-- DaveMorris - 13 Jul 2007

The schema contains the following :

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

-- DaveMorris - 13 Jul 2007

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

The schema contains the following :

   <xsd:complexType name="PropertyDescriptionType">
      <xsd:annotation>
      ....
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="vs:BaseParam">
            <xsd:attribute name="key" type="xsd:string">
               <xsd:annotation>
               ....
               </xsd:annotation>
            </xsd:attribute>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

But the example contains the following :

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
  </key>

1. The schema has attribute key, but the example has element key attribute name.
2. The schema has complexType PropertyDescriptionType, but the example has xsi:type VOSpaceProperty

I suspect I might be looking at the wrong versions of things. Can you add the latest schema and example(s) as attachments to this page, so that we can track the changes.

-- DaveMorris - 13 Jul 2007

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

-- DaveMorris - 13 Jul 2007

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

   <xsd:complexType name="PropertyDescriptionType">
      <xsd:annotation>
      ....
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="vs:BaseParam">
            <xsd:attribute name="key" type="xsd:string">
               <xsd:annotation>
               ....
               </xsd:annotation>
            </xsd:attribute>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

But the example contains the following :

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
  </key>

1. The schema has attribute key, but the example has element key attribute name.
2. The schema has complexType PropertyDescriptionType, but the example has xsi:type VOSpaceProperty

I suspect I might be looking at the wrong versions of things. Can you add the latest schema and example(s) as attachments to this page, so that we can track the changes.

-- DaveMorris - 13 Jul 2007

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

This is really a VOStandard issue - it is not VOSpace specific - In summary, the arguments for are

• Not having to keep repeating Dublin core metadata just to define an eumeration constant.
• having the enumeration constants collected together in one resource document allows easy identification of officially endorsed sets of constants within a single resource identifier cf. what is done for STC with standard coordinate systems.
• having the fragment part specifically identify the enumeration constant in question allows different semantics compared with a bare ivo identifier ( which in practical reality is actually a locator for a registry record) - the fragment identifies the actual xml that defines the enumeration constant/property.

VOspace allows the property URI to be a http URL for instance as well as an IVOA ID - in this case there would be no need for a fragment identifier for the property if the content at the http URL were simply the properly defintion without all the dublin core - the fragment convention is only for IVOA ids.

However, what explicitly are the problems that adopting this convention causes?

I've changed vote to '0', to indicate that we will be adopting the VOStandard format, but ther are still a few issues we need to sort out.

I'm wary of using the fragent identifier, because once it is used to refer to one part of the XML, it can't be used again. For example, the view and protocol elements both allow multiple child param elements.

If this URI

• ivo://net.ivoa.vospace/protocols#imaginary

• ivo://net.ivoa.vospace/protocols#imaginary/user

• ivo://net.ivoa.vospace/protocols#imaginary#user

This is going beyond the standard meaning of the # fragment identifier, so we would have to choose a specific syntax define it in our specification.

-- DaveMorris - 13 Jul 2007

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

-- DaveMorris - 13 Jul 2007

Votes

Property should have a type

-- PaulHarrison - 04 Jul 2007

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
    <type>xsi:integer</type>
  </key>

Votes

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

The schema contains the following :

   <xsd:complexType name="PropertyDescriptionType">
      <xsd:annotation>
      ....
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="vs:BaseParam">
            <xsd:attribute name="key" type="xsd:string">
               <xsd:annotation>
               ....
               </xsd:annotation>
            </xsd:attribute>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

But the example contains the following :

  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
  </key>

1. The schema has attribute key, but the example has element key attribute name.
2. The schema has complexType PropertyDescriptionType, but the example has xsi:type VOSpaceProperty

I suspect I might be looking at the wrong versions of things. Can you add the latest schema and example(s) as attachments to this page, so that we can track the changes.

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

This is really a VOStandard issue - it is not VOSpace specific - In summary, the arguments for are

• Not having to keep repeating Dublin core metadata just to define an eumeration constant.
• having the enumeration constants collected together in one resource document allows easy identification of officially endorsed sets of constants within a single resource identifier cf. what is done for STC with standard coordinate systems.
• having the fragment part specifically identify the enumeration constant in question allows different semantics compared with a bare ivo identifier ( which in practical reality is actually a locator for a registry record) - the fragment identifies the actual xml that defines the enumeration constant/property.

VOspace allows the property URI to be a http URL for instance as well as an IVOA ID - in this case there would be no need for a fragment identifier for the property if the content at the http URL were simply the properly defintion without all the dublin core - the fragment convention is only for IVOA ids.

However, what explicitly are the problems that adopting this convention causes? -- PaulHarrison - 04 Jul 2007

I've changed vote to '0', to indicate that we will be adopting the VOStandard format, but ther are still a few issues we need to sort out.

I'm wary of using the fragent identifier, because once it is used to refer to one part of the XML, it can't be used again. For example, the view and protocol elements both allow multiple child param elements.

If this URI

• ivo://net.ivoa.vospace/protocols#imaginary

• ivo://net.ivoa.vospace/protocols#imaginary/user

• ivo://net.ivoa.vospace/protocols#imaginary#user

This is going beyond the standard meaning of the # fragment identifier, so we would have to choose a specific syntax define it in our specification.

-- DaveMorris - 13 Jul 2007

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

The schema contains the following :

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

Votes

Property should have a type

-- PaulHarrison - 04 Jul 2007

Votes

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

This is really a VOStandard issue - it is not VOSpace specific - In summary, the arguments for are

• Not having to keep repeating Dublin core metadata just to define an eumeration constant.
• having the enumeration constants collected together in one resource document allows easy identification of officially endorsed sets of constants within a single resource identifier cf. what is done for STC with standard coordinate systems.
• having the fragment part specifically identify the enumeration constant in question allows different semantics compared with a bare ivo identifier ( which in practical reality is actually a locator for a registry record) - the fragment identifies the actual xml that defines the enumeration constant/property.

VOspace allows the property URI to be a http URL for instance as well as an IVOA ID - in this case there would be no need for a fragment identifier for the property if the content at the http URL were simply the properly defintion without all the dublin core - the fragment convention is only for IVOA ids.

However, what explicitly are the problems that adopting this convention causes? -- PaulHarrison - 04 Jul 2007

Thanks for adding this. I knew there were good reasons for it, just that I hadn't seen them explicity stated anywhere. This explanation will need to be included in the final document describing the schema.

I've changed vote to '0', to indicate that we will be adopting the VOStandard format, but ther are still a few issues we need to sort out.

I'm wary of using the fragent identifier, because once it is used to refer to one part of the XML, it can't be used again. For example, the view and protocol elements both allow multiple child param elements.

If this URI

• ivo://net.ivoa.vospace/protocols#imaginary

• ivo://net.ivoa.vospace/protocols#imaginary/user

• ivo://net.ivoa.vospace/protocols#imaginary#user

This is going beyond the standard meaning of the # fragment identifier, so we would have to choose a specific syntax define it in our specification.

-- DaveMorris - 13 Jul 2007

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>

Votes

Property should have a type

-- PaulHarrison - 04 Jul 2007

Votes

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

This is really a VOStandard issue - it is not VOSpace specific - In summary, the arguments for are

• Not having to keep repeating Dublin core metadata just to define an eumeration constant.
• having the enumeration constants collected together in one resource document allows easy identification of officially endorsed sets of constants within a single resource identifier cf. what is done for STC with standard coordinate systems.
• having the fragment part specifically identify the enumeration constant in question allows different semantics compared with a bare ivo identifier ( which in practical reality is actually a locator for a registry record) - the fragment identifies the actual xml that defines the enumeration constant/property.

VOspace allows the property URI to be a http URL for instance as well as an IVOA ID - in this case there would be no need for a fragment identifier for the property if the content at the http URL were simply the properly defintion without all the dublin core - the fragment convention is only for IVOA ids.

However, what explicitly are the problems that adopting this convention causes? -- PaulHarrison - 04 Jul 2007

Thanks for adding this. I knew there were good reasons for it, just that I hadn't seen them explicity stated anywhere. This explanation will need to be included in the final document describing the schema.

I've changed vote to '0', to indicate that we will be adopting the VOStandard format, but ther are still a few issues we need to sort out.

I'm wary of using the fragent identifier, because once it is used to refer to one part of the XML, it can't be used again. For example, the view and protocol elements both allow multiple child param elements.

If this URI

• ivo://net.ivoa.vospace/protocols#imaginary

• ivo://net.ivoa.vospace/protocols#imaginary/user

• ivo://net.ivoa.vospace/protocols#imaginary#user

This is going beyond the standard meaning of the # fragment identifier, so we would have to choose a specific syntax define it in our specification.

-- DaveMorris - 13 Jul 2007

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Votes

Property should have a type

-- PaulHarrison - 04 Jul 2007

Votes

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema
• Existing example

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Done -- PaulHarrison - 04 Jul 2007

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

This is really a VOStandard issue - it is not VOSpace specific - In summary, the arguments for are

• Not having to keep repeating Dublin core metadata just to define an eumeration constant.
• having the enumeration constants collected together in one resource document allows easy identification of officially endorsed sets of constants within a single resource identifier cf. what is done for STC with standard coordinate systems.
• having the fragment part specifically identify the enumeration constant in question allows different semantics compared with a bare ivo identifier ( which in practical reality is actually a locator for a registry record) - the fragment identifies the actual xml that defines the enumeration constant/property.

VOspace allows the property URI to be a http URL for instance as well as an IVOA ID - in this case there would be no need for a fragment identifier for the property if the content at the http URL were simply the properly defintion without all the dublin core - the fragment convention is only for IVOA ids.

However, what explicitly are the problems that adopting this convention causes? -- PaulHarrison - 04 Jul 2007

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Votes

Property should have a type

-- PaulHarrison - 04 Jul 2007

Votes

name	vote <-- -->	comment
DaveMorris	+1	proposer
PaulHarrison	+1

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

Update the schema and examples

Votes

Why multiple properties in a single document

For simplicity sake, I propose we only have one standard per resource document. If we only have one standard per document, then we don't need to bother with the complexity of an id or key attribute and we don't need to use #fragment identifiers in the URIs.

I know we have discussed this before, but I'd like to see the reasons for this explicitly stated as part of this discussion so that we can see if this makes sense.
As long as the reasons for combining multiple standards into a single resource document outweigh the problems and complexity it causes, then ok.

Votes

Don't use id attribute

On the other hand, if we use a different attribute, does this mean we have to redefine the meaning of the # fragment indentifier in a URL or URI (see comment on complexity of registering multiple standards in the same document).

Votes

Property should have a type

Votes

Property should have a regular expression

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema for registering properties, views and protocols.

The aim is to define extensions or modifications to the IVOA standard registration schema that will enable us to register and describe VOSpace properties, views and protocols.

• IVOA standard registration schema

• Existing schema (possibly out of date)
• Existing example (possibly out of date)

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Discussion of the VOSpace 1.1 property registration schema

This is a discussion page for the XML schema fo registering properties, views and protocols.

Although this discussion is associated with version 1.1 of the service specificication, the aim of this discussion is to define a registration schema that can be used by version 1.0 and 1.1 of the service specification.

Version 1.0 of the service specification refers to, but does not specify the XML schema for registering properties, views and protocols.

This is somewhere where we can post proposals and to enable interested parties to discuss the changes.

Please add your suggestion to this page and vote on other suggestions

• +1 if you agree
• 0 if you think the proposal is useful but needs more work
• -1 if you disagree with the proposal

If you register a 0 or -1 vote, then please add a link to a page outlining your objections or comments.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->