OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws-comment] XML Schema design for search WS


Hi Saašha - we have considered your suggestion to maintain dual schemas. We will add this to the list of suggestions to consider for future versions. 

  Thanks again for your comments and for your interest in this work.

--Ray

> -----Original Message-----
> From: Saašha Metsärantala [mailto:saasha@acc.umu.se]
> Sent: Friday, February 24, 2012 4:18 PM
> To: Denenberg, Ray; search-ws-comment@lists.oasis-open.org
> Subject: Re: [search-ws-comment] XML Schema design for search WS
> 
> Hello!
> 
> > The OASIS WS TC thanks you for
> > your comment of January 16
> > about schema design.
> Thanks Ray for your answer!
> 
> > There is no single "right way"
> > to design a schema
> That is true!
> 
> > valid instances can be created
> > which make no sense for the
> > searchRetrieve application.
> I would like to try to avoid that.
> 
> > In our schemas we have chosen
> > to define each element as
> > global so that it can be
> > imported by another schema.
> That represents a valid approach, of course!
> 
> > there may be other applications
> > [...] that may want to [...]
> > reference to specific elements.
> Of course, it is important to take that into account.
> 
> > it seems simpler [...] to
> > globalize all elements rather
> > than arbitrarily (or best guest)
> > select some but not others.
> It is!
> 
> I would like to suggest to combine these approaches. This could be done in
> different ways. One example is the following:
> 
> We could create one new schema where all elements defined there can be root
> elements.
> 
> The other schemas would be rewritten to mainly select and combine the elements
> defined in the new schema and define which elements are allowed to be used as
> root elements.
> 
> Thus, we could prevent many non-sense instances to validate without giving up
> the reusability of most elements.
> 
> Of course, one more schema would slightly increase the complexity of the
> overall design, but I consider that the flexibility such an approach can offer
> would combine well with the ability to avoid the validation of many non-sense
> instances.
> 
> Future versions of the new schema could add new elements without removing nor
> modifying previously defined elements, thus improving its forward
> compatibility. Future versions of the other schemas could focus on new ways to
> combine (previously defined or newly defined) elements.
> 
> Regards!
> 
> Saašha,



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]