[glue-wg] XML schema for GLUE 2.0

[David Horat]

A few comments.

On Tue, Jun 2, 2009 at 3:54 PM, JP Navarro <navarro at mcs.anl.gov> wrote:

> Another interesting and useful characteristic of a flattened XML
> rendering
> is that it's conceptually SQL tables and relationships rendered in XML.
>
> The various XML elements should correspond to GLUE 2 SQL tables, and the
> linkages between the XML elements should correspond to SQL foreign key
> references.


I also think it would be easier to map.

I would strongly suggest to enforce the implementation of all relations in
the XML in the way of Foreign Keys, as what we have done with LDAP. Appart
from that, you can also choose to use a concrete tree or not, but at least
you know you can navigate using a common way: Foreign Keys.


>
>
> An intriguing way to pull all of these ideas together would be to
> develop
> a REST compliant URL interface for accessing GLUE 2 information, where
> that
> interface accesses information in a SQL rendering OR a flattened XML
> rendering of GLUE 2.  That native SQL or flattened XML content can be
> returned to clients as CSV, XML, JSON, or other formats back to the REST
> client.


The XML output is what it will also be covered by the XML rendering. For
other renderings, such as CSV of JSON we will have to make separated
documents. Anyway, I think that with XML should be enough at the moment.


>
>
> Client request -> GLUE 2 REST ---> GLUE 2 SQL or flattened XML
> repository
> Client response is CSV, XML, JSON, or other rendering of repository
> GLUE 2
>
> JP
>
> On Apr 24, 2009, at 9:21 AM, JP Navarro wrote:
>
> > Hi Balazs,
> >
> > As others have described, there are several design, implementation,
> > and
> > support advantages to a decomposed/flattened approach.  With unique
> > IDs
> > and links between the entities, it should be fairly straightforward to
> > compose information into a large agreed/standard rendered document.
> >
> > There are also discovery performance and functionality advantages and
> > disadvantages to both approaches.
> >
> > It seems to me like this implementation approach doesn't contradict
> > the
> > GLUE2 specification since it describes the same entities, attributes,
> > and relationships, although I think you're right that it may lead us
> > to
> > modify the current rendering specification to include a decomposed
> > one. An
> > interesting questions is whether we have to have a single XML
> > rendering
> > in support of interoperability or if we can support several
> > renderings?
> > We're already willing to accommodate XML, LDAP, and SQL renderings, so
> > why not accommodate multiple XML renderings too?
> >
> > Regards,
> >
> > JP
> > On Apr 24, 2009, at 8:56 AM, Balazs Konya wrote:
> >
> >> hi,
> >>
> >> David Horat wrote:
> >>> This is the same approach that has been taken for the LDAP
> >>> implementation. To make this possible, IDs must be globally
> >>> unique. I
> >>> support this approach as it lets the implementation to be less
> >>> coupled
> >>> to the technology used and facilitates interaction between different
> >>> systems.
> >>
> >> we'd be rather careful going this way. in the past within nordugrid
> >> we
> >> found a common, agreed structure (at that time within nordugrid) very
> >> important.
> >>
> >> i have doubts that flattening everything will give us better
> >> interoperability.
> >>
> >> in any case, the issue/proposal worth to be discussed on a phonecall.
> >>
> >> one more note: the rendering was an important part of the public
> >> comment
> >> specification. Turning everything upside down e.g. in xml may need
> >> glue
> >> to enter into another public comment period.
> >>
> >>
> >> cheers,
> >> Balazs Konya
> >> _______________________________________________
> >> glue-wg mailing list
> >> glue-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/glue-wg
> >
>
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg
>



-- 
David Horat
Software Engineer – IT/GD – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born
Address: 1211 Geneva - Switzerland, Office: 28/R-003
Phone +41 22 76 77996
Fax +41 22 76 68178 (fax to email service)
Web: http://cern.ch/horat
Web: http://davidhorat.com/
Profile: http://linkedin.com/in/davidhorat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20090611/831da98e/attachment.html