Breininger, Kathryn R wrote:
4CA074FFE64C114B9DEC89701310DCF207442FA0@XCH-NW-1V2.nw.nos.boeing.com"
type="cite">
This is a meeting reminder and draft agenda for our meeting scheduled
for Thursday June 12th at 8:00 am Pacific Time. Call in info and draft
agenda follow:
The telecon number and password:
USA toll: 1-210-795-0625
USA Toll free: 866-617-3597
PARTICIPANT PASSCODE (same for all countries): 1739140
International numbers;
France
Toll: 33-1-70-70-84-56
Toll free: 080-510-0984
UK
Toll: 44-20-7108-6391
Toll free: 0800-279-9632
For other countries please contact Kathryn directly.
Draft Agenda:
1. Approval of minutes
Approved
4CA074FFE64C114B9DEC89701310DCF207442FA0@XCH-NW-1V2.nw.nos.boeing.com"
type="cite">
2. Minute taker (volunteer needed - last minute takers: Carl, Farrukh,
Nikola)
Minute Taker: Farrukh
Attendees: Farrukh, Carl, Nikola
4CA074FFE64C114B9DEC89701310DCF207442FA0@XCH-NW-1V2.nw.nos.boeing.com"
type="cite">
3. ebXML version 4.0 discussion
Canonical queries
- Farrukh gave brief overview
- Unlike past we now build queries bottom up adding predicates
for each parameter. In the past we started with complete query and
pruned out predicates for which parameters were not supplied
- Most parameters now tend to be optional
- New matchOnAnyParameter parameter may be used by queries to
allow LOGICAL OR instead of LOCAL AND (default)
- Implementations will likely require code to implement support
for building the query based on supplied parameters
- QueryExpression syntax is no longer needed to be exposed and
the query may be implemented in any manner suitable (e.g. SQL, XQuery,
SPARQL, etc.). The only thing that matters is the query parameter
interface. This is what we will specify in spec.
- Carl: What if no parameter is specified
- Farrukh: Matches all objects which can be quite big. Solution
already exists in form of current spec saying that implementations may
impose a maxResults as defined in Iterative Query feature
- Issue: Nikola: We need a pattern for specifying version
constraints on query results. For example a version parameter on
queries could have values LATEST, ALL or specified version.
- BasicQuery
- Choice of parameters seems reasonable
- Semantic seem reasonable except for path semantics in issue
below
- status, objectType and classifications currently expect node
path as opposed to node id so they can match node and its descendant
node.
- Nikola: we could do the same with id it would just require a
different query in the implementation
- Issue: Carl: What if we do not want to match descendant
nodes. Currently there is no way to do that
- Farrukh: We could spec that a trailing '/' implies match
sub-nodes else do exact match
- Nikola: What about using XPath
- Farrukh: Xpath is too complex for node paths
- ACTION: Nikola: will look at XPath for XML node in canonical
ObjectType
- FindRelationshipsQuery
- Carl: Same path issue from BasicQuery applies here for all
xxType parameters. All Agreed.
- Choice of parameters seems reasonable
- Semantic seem reasonable except for path semantics issue
- Issue: Carl: Need consistency in description of query params
wherever possible (e.g. wild card hints)
- Farrukh: These editorial fixes can be easily done later
- FindRelatedObjectsQuery
- Farrukh: Identical parameter interface to
FindRelationshipsQuery. Difference is that we return RegistryObjects on
the other side of the Associations that match FindRelationshipsQuery
query
- Carl: Same path issue from BasicQuery applies here for all
xxType parameters. All Agreed.
- Choice of parameters seems reasonable
- Semantic seem reasonable except for path semantics issue
4CA074FFE64C114B9DEC89701310DCF207442FA0@XCH-NW-1V2.nw.nos.boeing.com"
type="cite">
4. Other items
ACTION: Nikola: Please maintain the issue list you had started in the
last few months for RegRep 4
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
|