[opensearch:374] OpenSearchDescription XSD

[Oscar Fonts]

Hi,

Where can I find an xml schema of the OpenSearch description document?

Thanks,

Oscar.

--
You received this message because you are subscribed to the Google Groups "OpenSearch" group.
To post to this group, send email to opens...@googlegroups.com.
To unsubscribe from this group, send email to opensearch+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensearch?hl=en.

[Oscar Fonts]

Auto-responding:

I've found an XSD in opensearchvalidator.com source code:
http://opensearchvalidator.codeplex.com/

Not JAXB-XJC friendly, though.



2010/5/5 Oscar Fonts <oscar.fo...@gmail.com>:

[DeWitt Clinton]

Cool.  If you want to polish that up we can add it to the under-used repository at http://code.google.com/p/opensearch/ and link to it from the wiki.

-DeWitt

[Tatham Oddie]

Hi,

 

I’m the project owner of the validator.

 

What would you like to see cleaned up about the XSD?

 

What is required to make it JAXB-XJC friendly, and would these changes require a fork of the XSD or does it stay compatible?

 

http://opensearchvalidator.codeplex.com/SourceControl/changeset/view/40737#385239

 

 

--

Tatham Oddie

au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie

[Oscar Fonts]

Tatham,

I wanted to automatically generate the code to load (unmarshall)
descriptions into Java classes, via JAXB-XJC. The code generated with
the XSD you pointed at is not usable, because of that nested
sequence/choice under OpenSearchDescription:

---
<xs:element name="OpenSearchDescription">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
---

I've tweaked the XSD to read:

---
<xs:element name="OpenSearchDescription">
<xs:complexType>
<xs:all>
---

This happens to be a not valid XSD because some list elements (like
Url) have maxOccurs="unbounded", and that is not allowed under
<xs:all>. But, well, with this change, JAXB-XJC is generating the good
Java classes.

Using <xs:sequence> would allow for unbounded elements, but then they
have to appear in the same order as described in the XSD, which would
not validate almost any of the existing description documents in the
wild.

The original XSD will consider valid a description with, for instance,
two <ShortName> elements, if I'm not understanding it wrong, so it is
a bit lax. But better than being too strict, right? :)

Then, it seems that there is not a definite -elegant- way to express
in XSD an unordered set of child elements some of which are
repeatable, as is the case with OpenSearchDescription. Or not one that
I am aware of (I'm not an XSD expert anyway).


Oscar.



2010/5/6 Tatham Oddie <tat...@oddie.com.au>:

[Tatham Oddie]

Hi Oscar,

I forwarded this thread around within my organisation and got the below
responses. None good unfortunately. :s

--
Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie

-----Original Message-----
From: Colin Savage [mailto:colin....@readify.net]
Sent: Friday, 7 May 2010 9:03 AM
To: Tatham Oddie; Readify Tech
Subject: RE: [opensearch:378] Re: OpenSearchDescription XSD

Go for it.

Regards,
Colin Savage
Readify | Senior Developer
M: +61 401 426 178 | C: colin....@readify.net

-----Original Message-----
From: Tatham Oddie [mailto:tat...@oddie.com.au]
Sent: Friday, 7 May 2010 9:01 AM
To: Colin Savage; Readify Tech
Subject: RE: [opensearch:378] Re: OpenSearchDescription XSD

Bugger. Thanks Colin.

Do you mind if I forward your replies back to the
opens...@googlegroups.com list, as-is?

--
Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie

-----Original Message-----
From: Colin Savage [mailto:colin....@readify.net]
Sent: Friday, 7 May 2010 9:00 AM
To: Tatham Oddie; Readify Tech
Subject: RE: [opensearch:378] Re: OpenSearchDescription XSD

I don't think you'll be able to make the sequence random and enforce the
number of occurrences. It will make the schema ambiguous and it won't
validate.

Regards,
Colin Savage
Readify | Senior Developer
M: +61 401 426 178 | C: colin....@readify.net

-----Original Message-----
From: Tatham Oddie [mailto:tat...@oddie.com.au]
Sent: Friday, 7 May 2010 8:57 AM
To: Colin Savage; Readify Tech
Subject: RE: [opensearch:378] Re: OpenSearchDescription XSD

Right - that's what we have now but JAXB-XJC can't generate proxy classes
for it.

Changing the XSD to this makes it work:

<xs:element name="OpenSearchDescription">
<xs:complexType>
<xs:all>

But that's not valid any more as it defines the sequence of the elements
(irrelevant for deserializing, but means the XSD can't be used to validate
source documents).

I'm wondering if there's an option C that is both valid XSD and compatible
with JAXB-XJC. :)

Alternatively we'll just have to branch the XSD. :(

More detail in Oscar's email below.

--
Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie

-----Original Message-----
From: Colin Savage [mailto:colin....@readify.net]
Sent: Friday, 7 May 2010 8:53 AM
To: Tatham Oddie; Readify Tech
Subject: RE: [opensearch:378] Re: OpenSearchDescription XSD

What you want is an unbounded sequence of choices (min = 0, max = 1)

<root xmlns="http://tempuri.org/XMLSchema.xsd">
<bar></bar>
<bar></bar>
<baz/>
<foo/>
</root>

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
elementFormDefault="qualified"
xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<xs:element name="root">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element name="foo"/>
<xs:element name="bar"/>
<xs:element name="baz"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Regards,
Colin Savage
Readify | Senior Developer
M: +61 401 426 178 | C: colin....@readify.net

-----Original Message-----
From: Tatham Oddie [mailto:tat...@oddie.com.au]
Sent: Friday, 7 May 2010 8:32 AM
To: Readify Tech
Subject: FW: [opensearch:378] Re: OpenSearchDescription XSD

Any XSD experts here? :)

We want to model an XSD that validates specific children, some required,
some only allowed once, and some repeating, without dictating the order.

For example:

<Parent>
<Child3>Hi</Child3>
<Child1>Hi</Child1>
<Child3>Hi</Child3>
</Parent>

With rules like:

Child 1 is required once.
Child 2 is optional.
Child 3 is required at least once, but can exist multiple times.
Any order is fine.

More details below.

--
Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 280 9140, skype: tathamoddie