W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2003

RE: Minutes, 24 Sept 2003 WS Desc WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 30 Sep 2003 16:19:45 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2014BC9A1@RED-MSG-30.redmond.corp.microsoft.com>
To: "David Orchard" <dorchard@bea.com>, <www-ws-desc@w3.org>

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> Behalf Of David Orchard
> Sent: Monday, September 29, 2003 5:44 PM
> To: www-ws-desc@w3.org
> Subject: RE: Minutes, 24 Sept 2003 WS Desc WG FTF
> I'm confused by what happened on this.  My understanding is that the
> WG made a decision about what it thought was the best approach for
> component designators.  It then asked the TAG what the TAG thought of
> WSDL WG's decision.  The TAG has certainly not said that the WSDL WG's
> approach is poor.  In fact, the TAG hasn't said anything.  This has
> annoying to me, but then the TAG is trying to get to Last Call on the
> arch document so the rationale is reasonable.

The idea was to see if there was another approach that was not so
clearly broken as the approach in our draft, thus allowing us to improve
the situation while waiting for the TAG to make progress (which has not
been evident.)  After my recent XInclude experience, I think I
understand fragment identifiers and media types better than I did
before, which just confirms to me how broken our current approach is.
I've been working on fragment identifier syntax and applications for XML
for several years now and the result of my experience is to stay as far
away from frag-ids as possible.

> I should point out to the
> group that I did volunteer to attend the f2f to cover this issue if it
> came up.  
> I had not realized that the WSDL WG was being held up - seemed to me
> onus was on the TAG to say yay or nay.

As we get closer to a stable draft, having something which is
inconsistent with fragment syntax (as this clearly is) seems like a
magnet for negative comments.

> I also don't think that using URIs for component designators is solely
> RDF issue.  It seems to be more of a web architecture issue - hence
> the TAG was asked :-).

I welcome a TAG solution in time to put the syntax back in the main
draft.  Until then, it seems appropriately conservative to limit the
dependency of out spec on the TAG's agenda.

> I imagine that the media type registration will
> need to say something about the frag-id syntax, so I don't think the
> dependency is removed.

If we don't use frag-id syntax for our designators, we don't have to
invent anything for the media type registration, and thus the dependency
is certainly removed.  However, after a modest amount of discussion, it
is apparent that the WG doesn't have a good idea of which approach would
be better than the one we have now.  Moving the appendix to a subsequent
document seems like the easiest way to get the TAG's attention :-).

> I encourage the group to reconsider it's decision to move component
> designators into the RDF mapping document.  Failing that, I will
> the TAG of the WSDL WG's decision and then let the chips fall where
> may.

I think that at this point the most efficient use of time is for the TAG
to complete its deliberations.  At that point the WG can resume this
work.  Removing the "half-baked" section out of our spec ensures that
our primary deliverables are properly insulated from this issue.  

> Cheers,
> Dave
> >
> > -------------------------------------------------------
> > 10:00 WSDL Component Designators [46]
> >       Draft TAG finding [47]
> >
> >  [46]
> > http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0075.html
> >  [47] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0054.html
> >
> >
> > [No minutes?  Chair recalls that we were unable to quickly
> > choose an ideal
> > candidate from the TAG draft finding, and thus approved
> > moving the appendix into the RDF mapping document to
> > eliminate a dependency of unknown duration.]
> >
> >
Received on Tuesday, 30 September 2003 19:22:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:34 UTC