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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: XQuery Support (Was Re: [regrep] Implementing CCTS in Registry -further thoughts)


I too think its a good idea, although I disagree with Max's statement 
that it is more powerful.  Its certainly more flexible, and probably 
easier to learn than filter query, but more powerful?  Filter query was 
designed to suit ebRIM in particular.  If Filter Query doesn't support a 
query that XQuery can, its probably only because the people designing 
Filter Query didn't see it as a useful query.

-matt

Max Voskob wrote:

>Hi guys,
>
>I think xQuery will be a great idea. It's much more powerful than your query
>mechanism (personal opinion!) and much more robust.
>On the other hand, xPath is too weak to produce a complex query. I don't
>think xPath is worth the effort.
>
>Cheers,
>Max
>
>
>----- Original Message -----
>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
>To: "David RR Webber - XML ebusiness" <Gnosis_@compuserve.com>
>Cc: "Duane Nickull" <duane@xmlglobal.com>; "OASIS Registry List"
><regrep@lists.oasis-open.org>; "Farrukh Najmi" <farrukh.najmi@sun.com>;
>"Matthew MacKenzie" <matt@mac-kenzie.net>
>Sent: Wednesday, February 19, 2003 3:25 AM
>Subject: XQuery Support (Was Re: [regrep] Implementing CCTS in Registry -
>further thoughts)
>
>
>  
>
>>>Functionally everything still works - anyone can query against
>>>the CAM template XML to discover all the relationships -
>>>by exploiting the mechanisms inside the template itself.
>>>      
>>>
>>Perhaps we should look toward possibly supporting XQuery/XPath Full-Text
>>Search in V4 (http://www.w3.org/TR/xmlquery-full-text-requirements/)?
>>Depending on the timing/progress of the Working Draft, of course.
>>
>>- Joe
>>
>>
>>David RR Webber - XML ebusiness wrote:
>>    
>>
>>>Message text written by Chiusano Joseph
>>>      
>>>
>>>MY QUESTION:  Wouldn't we most like represent the Association Core
>>>Component (Person.Residence.Address) as we would represent any Aggregate
>>>Core Component, but with an association of "Inherits From" (a new
>>>assocationType) - that is, Residence.Address would inherit from
>>>Address.Details?
>>><<<<<<<<<<
>>>
>>>Joe,
>>>
>>>I believe this approach is fraught with lots of "gotchas" - especially
>>>supporting business context structure changes.
>>>
>>>That's why I see that the separation of the assembly associations
>>>into the CAM template great simplifies all this.
>>>
>>>Functionally everything still works - anyone can query against
>>>the CAM template XML to discover all the relationships -
>>>by exploiting the mechanisms inside the template itself.
>>>
>>>But - you are not therefore attempting to use the registry to
>>>handle assembly, schema fragments and much more.
>>>
>>>Of course you can still add regular registry associations
>>>from the CAM template entries to other entries in the
>>>registry - but attempting to use these as the means to
>>>represent all the subtly of assembly and context - is
>>>not optimal.
>>>
>>>Cheers, DW.
>>>      
>>>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



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


Powered by eList eXpress LLC