Difference: VOSpace11Reg (1 vs. 12)

Revision 122012-06-26 - root

 
META TOPICPARENT name="VOSpaceHome"
Changed:
<
<
VOSpace home page
>
>
VOSpace home page
 

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer



Revision 112007-12-07 - PaulHarrison

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Changed:
<
<
>
>
  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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer



<--  
-->

Revision 102007-12-07 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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.


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

-- DaveMorris - 07 Dec 2007


 

Update the schema and examples

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

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

Deleted:
<
<

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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

 
Deleted:
<
<
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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
DaveMorris 0 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
Deleted:
<
<

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007


Perhaps the VOTable enumeration isn't the best one to choose then. Is there another established set we could use ? Perhaps the set of basic types from XML schema - that would give us integers, dates and URIs etc.

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

It would be good if we can find an existing set that meets our needs. I'd prefer to avoid defining yet another enumeration of basic data types.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison +1

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.

-- PaulHarrison - 04 Jul 2007


This goes back to a request from Matthew to allow typing of the properties (link and link).

Basically, the request was to be able to embed something like this in a property :

  <property uri="ivo://net.ivoa/properties/color" type="myschema.xsd">
    <color>
      <red>123</red>
      <blue>234</blue>
      <green>89</green>
    </color>
  </property> 

In the email discussion that followed (link).

I suggested that rather than put the type information in the message, the type information should be part of the property definition.

In another email (no link), I think you pointed out that the information in the example XML fragment could be encoded as a string of threee digits 123:234:89.

In which case, providing a regular expression in addition to the text description in the property definition

  <key name="balance" xsi:type="vsp:VOSpaceProperty">
    <description>
The colour balance, represented as three decimal values separated by ':' for red, blue and green.
Example "123:234:89"
    </description>
    <type>xsi:string</type>
    <regex>{0-9}+:{0-9}+:{0-9}+</regex>
  </key>
would provide a machine readable syntax that could enable services and UI developers to validate user input.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0
 


<--  
-->

Revision 92007-07-13 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

Done -- PaulHarrison - 04 Jul 2007

Added:
>
>

 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

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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?

Added:
>
>
 -- PaulHarrison - 04 Jul 2007
Added:
>
>

 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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
DaveMorris 0 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Added:
>
>

 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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.

-- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

Added:
>
>

 Perhaps the VOTable enumeration isn't the best one to choose then. Is there another established set we could use ? Perhaps the set of basic types from XML schema - that would give us integers, dates and URIs etc.
Deleted:
<
<
I'd prefer to avoid defining a whole new enumeration of our own basic data types.
 
  <key name="size" xsi:type="vsp:VOSpaceProperty">
    <description>The size of the data item</description>
    <unit>bytes</unit>
    <type>xsi:integer</type>
  </key>
Added:
>
>
It would be good if we can find an existing set that meets our needs. I'd prefer to avoid defining yet another enumeration of basic data types.
 -- DaveMorris - 13 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison +1

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.
Added:
>
>
-- PaulHarrison - 04 Jul 2007


This goes back to a request from Matthew to allow typing of the properties (link and link).

Basically, the request was to be able to embed something like this in a property :

  <property uri="ivo://net.ivoa/properties/color" type="myschema.xsd">
    <color>
      <red>123</red>
      <blue>234</blue>
      <green>89</green>
    </color>
  </property> 

In the email discussion that followed (link).

I suggested that rather than put the type information in the message, the type information should be part of the property definition.

In another email (no link), I think you pointed out that the information in the example XML fragment could be encoded as a string of threee digits 123:234:89.

In which case, providing a regular expression in addition to the text description in the property definition

  <key name="balance" xsi:type="vsp:VOSpaceProperty">
    <description>
The colour balance, represented as three decimal values separated by ':' for red, blue and green.
Example "123:234:89"
    </description>
    <type>xsi:string</type>
    <regex>{0-9}+:{0-9}+:{0-9}+</regex>
  </key>
would provide a machine readable syntax that could enable services and UI developers to validate user input.

-- DaveMorris - 13 Jul 2007

 

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0
Deleted:
<
<
 


<--  
-->

Revision 82007-07-13 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

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.

Added:
>
>
-- DaveMorris - 13 Jul 2007
 

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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

Deleted:
<
<

 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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
DaveMorris 0 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.
Added:
>
>
-- DaveMorris - 13 Jul 2007
 

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

Added:
>
>
Perhaps the VOTable enumeration isn't the best one to choose then. Is there another established set we could use ? Perhaps the set of basic types from XML schema - that would give us integers, dates and URIs etc.

I'd prefer to avoid defining a whole new enumeration of our own basic data types.

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

-- DaveMorris - 13 Jul 2007

 

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison +1

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0



<--  
-->

Revision 72007-07-13 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

Done -- PaulHarrison - 04 Jul 2007

Added:
>
>
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

Why are we trying to squeeze multiple standards into a single resource 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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
DaveMorris 0 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Changed:
<
<
The schema pointed to by the link at the top of the page contains the following :
>
>
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>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison +1

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0



<--  
-->

Revision 62007-07-13 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

Done -- PaulHarrison - 04 Jul 2007

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
DaveMorris 0 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Added:
>
>
The schema pointed to by the link at the top of the page contains the following :
 <xsd:attributeGroup name="identifier">
      <xsd:attribute name="id" type="xsd:NCName" use="required">
         <xsd:annotation>
         ....
         </xsd:annotation>
      </xsd:attribute>
   </xsd:attributeGroup>
However, I don't think this is used in the rest of the schema. In which case, can we remove it.
 

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison +1

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0



<--  
-->

Revision 52007-07-13 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

Done -- PaulHarrison - 04 Jul 2007

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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

Added:
>
>

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
refers to the definition for my new imaginary protocol, and that protocol has two params, 'user' and 'pass', we can't use the standard fragment identifier to refer to them. This is not unsolveable, but we would need to define a new (VOSpace specific) convention for how we refer to specific params within a protocol or view element.

  • ivo://net.ivoa.vospace/protocols#imaginary/user
or
  • ivo://net.ivoa.vospace/protocols#imaginary#user
are possible forms.

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

name vote comment
Changed:
<
<
DaveMorris +1 proposer
>
>
DaveMorris 0 proposer
 

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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 that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.

note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?


There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

Votes

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

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.


I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.

Votes

name vote comment
DaveMorris +1 proposer
PaulHarrison 0



<--  
-->

Revision 42007-07-04 - PaulHarrison

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

Changed:
<
<
>
>
  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

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer
Added:
>
>
Done -- PaulHarrison - 04 Jul 2007
 

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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.

Added:
>
>

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

name vote comment
DaveMorris +1 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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).

Added:
>
>

note that this attribute is of type xsd:NCName so that there is not the same problems as were highlighted for STC where xsd:ID is used - (note that in the latest version of the schema this has been renamed to 'name' ) - I think that it does not have any bearing on being able to use the fragment identifier (see http://www.faqs.org/rfcs/rfc2396.html sec 4.1) as it is up to the media type to define what the fragments mean. It would be better though in the long run if it were simply xsd:string with a regex restriction that conforms to the uric BNF of rfc2396.
 
Added:
>
>
note again this is really a VOStandard issue.

-- PaulHarrison - 04 Jul 2007

 

Votes

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?
Added:
>
>

There is no mention of this in the VOSpace Standard itself, but I guess that it would be a sensible addition - I would be less happy about adopting the existing type enumeration in votable as is, partially because it includes distinctions that are meaningless given that the formal type of the parameter value is always string in the VOSpace interface (eg. float/double) and also because it does not include useful stuff like date....

-- PaulHarrison - 04 Jul 2007

 

Votes

name vote comment
DaveMorris +1 proposer
Added:
>
>
PaulHarrison +1
 

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.
Added:
>
>

I have the feeling that this might be a very seldom used feature in practice - I cannot think of a use case for it at the moment - but I guess that an optional element would be fine.
 

Votes

name vote comment
DaveMorris +1 proposer
Added:
>
>
PaulHarrison 0
 



<--  
-->

Revision 32007-07-04 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
VOSpace home page

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.

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.

Added:
>
>

Update the schema and examples

Can we update the schema and examples to match the latest schema from the registry group.

Votes

name vote comment
DaveMorris +1 proposer

Why multiple properties in a single document

Why are we trying to squeeze multiple standards into a single resource 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

name vote comment
DaveMorris +1 proposer

Don't use id attribute

As a general rule, we should avoid using an id attribute. This has caused a lot of problems with other schema.
If register a property with id='owner', then we have to ensure that no other registry document, now or in the future, contains id='owner' anywhere the document.

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

name vote comment
DaveMorris +1 proposer

Property should have a type

A basic type attribute to indicate what data type the property contains, string, integer, date etc.
For practical reasons, should we adopt the existing type enumeration used in votable ?

Votes

name vote comment
DaveMorris +1 proposer

Property should have a regular expression

A property definition may include a 'regex' element containing a regular expression which constrains the allowed syntax of the property.

Votes

name vote comment
DaveMorris +1 proposer
 


<--  
-->

Revision 22007-05-17 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"
Added:
>
>
VOSpace home page
 

Discussion of the VOSpace 1.1 property registration schema

Changed:
<
<
This is a discussion page for the XML schema fo registering properties, views and protocols.
>
>
This is a discussion page for the XML schema for registering properties, views and protocols.
 
Added:
>
>
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.
 
Changed:
<
<
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
>
>
Deleted:
<
<
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.
Added:
>
>
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.



<--  
-->

Revision 12007-05-17 - DaveMorris

 
META TOPICPARENT name="VOSpaceHome"

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.



<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback