XSD - new VALID schema

Petr Kubanek Petr.Kubanek at obs.unige.ch
Thu Aug 10 08:06:13 PDT 2006


Hi,

description should not be string. You can put HTML tags to string without escaping them. It have to extend xs:anyType

  <xs:complexType name="Description"> 
    <xs:simpleContent> 
      <xs:extension base="xs:string">

change to

  <xs:complexType name="Description"> 
    <xs:simpleContent>
      <xs:extension base="xs:anyTag">

That will enable to do contructs like:

        <Description> This VOEvent packet resulted from observations  
            made with <a href=http://www.raptor.lanl.gov>Raptor</a> AB at Los Alamos. 
        </Description> 

instead of:

        <Description> <![CDATA[This VOEvent packet resulted from observations 
            made with <a href=http://www.raptor.lanl.gov>Raptor</a> AB at Los Alamos. ]]>
        </Description>

the first one is legal (with xs:anyType) and I found it nicer. And there are still methods in parsers to extract text between tags, at least I'll expect them.

And I would like to see role this way:

      <xs:attribute name="role" default="observation">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="observation"/>
            <xs:enumeration value="prediction"/>
            <xs:enumeration value="utility"/>
            <xs:enumeration value="test"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>

I know that specification is a bit vague about that, saying that others string might be possible, but let's for the moment left generalities. If we know about other string, put them to restriction now, otherwise leave them. Leaving it free will lead developers to create new ad-hoc type such as "observation-prediction", "hypothesis", "retraction" (because they do not understand Citations) and so on. That's not about central planing, that's about sane balance between what can be left free and what must be enforced - role is definitly one of few default parametes, and if you did not specify content(*), you will just see all possible mess mentioned above in it.

And of course I would like to see changes in specification, saying that role can be one of that four, leaving magic formula about others, not-yet know contents.

Petr

(*) OK, you can create special table listing all possible values of role, but isn't that duplication of work?

Roy Williams wrote:
> Petr
> 
> Thank you for your efforts. However yesterday I already uploaded a  new 
> schema with both your suggested changes and those suggested by  others 
> in the RFC process (i.e. the new "format" tag for  Description). All 
> previously valid documents should still be valid.
> 
> It is at
> http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd
> 
> The schema validates under Oxygen and XMLSpy (as with all previous  
> published schemas). Please tell me if you find any problems, and  
> especially if you have an XML tool that finds the schema invalid.
> 
> Roy



More information about the voevent mailing list