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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

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


Subject: Re: Implementation of XML QUERY]


Message text written by Nikola Stojanovic
> It seems to me that it would be very difficult to claim that we
have it ("Ad Hoc" query mechanism) if we don't specify what it is.
<<<<<

Nikola,

Totally!   I believe Scott HInkelmans comments about scope
also point up this need.

Ad hoc querying (AHQ) from the business perspective can be a very
different animal from programmer level AHQ.

Let me start a ball rolling by trying some categorization here,
and we can agree or disagree from there!

We also have to be careful here to differentiate between
Registry (metadata querying) and Repository (business
content querying).

End User AHQ/MDR - metadata registry

1)  Schema/DTD/XML definition lookup either directly
    (certain kind of ID referencing system(s)) or 
     via domain / context.  
    Note: including versioning is also important.
 
2)  Dictionary discovery of industry specific nouns
    and terms 
    ('keyword' style searching + context relates).

3)  Ability to cross-reference by a reference ID
   ('see also' and 'where used').

4)  Business process discovery/querying 
    ('show all where' crossdomain searching as 
     opposed to drilldown)

5)  Trading partner process semantics discovery.

6)  Classification scheme discovery/querying 

7)  Ability to publish and make available for
    re-use the common AHQ/MDR's via a simple 
    [method(valueslist)] approach.

End User AHQ/BCR - Business Content Repository:

1) Industry / Business Process specific, and therefore has
   a limited dictionary of familiar search nouns to choose 
   from.  (example: library of magazine articles, published
   photographs, authors, publishers, chronology).

2) 'Canned' complex queries will target common business
     problems, but allow users a smorgsbord of criteria
     (typically deployed via interactive form mode).
    Example:  classification, topic, dateperiod.

    Description: find all 'magazine editorial comments' 
     classification relating to 'rainforest'  topic 
    between '1990 and 1992' dates.

3) Business A2A mode where a repository is looking to 
     provide industry specific services to answer common
     requests (example:  catalogue consolidation - an
     then asking : partnumber, price, instockqty,
     shipmenttime).

4) Ability to publish and make available for re-use common
     AHQ/BCR's via a simple [method(valueslist)] approach.

Programmer AHQ/MDR  (items beyond lists above)

1) Ability to query RIM

2) Ability to query and view XML content in raw mode
   in XML enabled viewer with URL's live.

3) Ability to assemble own query statements and 
   provide access path with joins.

4) Ability to get back error messages if query 
   syntax is invalid / not allowed.

5) Ability to access and return XML metadata fragments 
   directly for use in programming manipulation.

6) Ability to expose external references to other
   registries via URL:Reference that is a live 
   linkage.

Programmer AHQ/BCR  (items beyond lists above)

7) Ability to call stored procedures and chain 
   results via joins to additional query terms.

8) Ability to access business content by profile
   or domain (channels).  Allows use of 
   end user access rights to business content.

I decided against including here "Ability to run distributed
queries where query results are expansion of external
references"  since this is really a behaviour that can
be built external to the registry using spidering and
other techniques by looking up any external references
the registry returns to you.

I've just penned this quickly - so hopefully I've not
introduced too much unclear terminology and the sense
and direction are fairly clear to allow us to understand
what it is we can achieve here given the constraints 
we have on our own resources.

If we can distill a simple strategy here to give real
business value for the ROI of defining a ADQ service
API that is interoperable across everyones proprietary
registry implementations then that's what I'd like to
see us striving for.

Thanks, DW.


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC