RE: Draft Finding on AbstractComponentRefs-37 issue

Hi David,

I've been catching up on my www-tag back log. Thanks for taking a crack at
writing this up... I have a few comment below.

Thanks,

Stuart
--

> 1 TAG Recommendation
> The TAG consensus is that description languages - such as WSDL, 
> XML Schema, OWL - should define fragment identifiers for identifying
> a language's abstract components. The TAG supports the use of fragment
> identifiers by the WSD working group.

I suggest replacing: 

"...should define fragment identifiers for identifying a language's abstract
components." 

with

"...may use URI including fragment identifiers for denoting(identifying)
abstract components described by that language."

I know that's backpedaling a bit wrt to the 'should' in the middle of the
sentence above. On the whole I'm happy that they 'may' use URI that include
fragment identifiers to denote abstract components described by instances of
the language. I'm less happy with the stronger 'should' unless we also
resolve httpRange-14 that way.

Also, I think we need to be clear that we are talking about the abstract
components that the language (WSDL, XML Schema...) is being used to describe
and rather than the abstract components of the description language itself.


> Good Practice
> Description languages that identify abstract components 
> should define a fragment identifier syntax for these 
> components.

Suggest rewriting as:

"Description languages that describe abstract components may make use of
fragment identifiers in generating identifiers for the abstract components
described."

> The TAG does believe that the issue of identifying abstract components
> and the use of namespace names has architectural implications for the 
> Web. The TAG has consensus that a vocabulary can recommend that an 
> instance of the vocabulary is available upon de-referencing the namespace
name. 
>
> Good Practice
> Description languages that identify abstract components should make 
> available an instance of the language at the URI used for identifying 
> the abstract component. 

I have no idea what the paragraph above and the Good Practice note that
follows it are trying to say. Actually, the Good Practice note is the more
accessible, but the paragraph before it looses me.

I think the spirit of the good practice note is (maybe):

"The identifier used to denote an abstract component should be useable to
retrieve a representaion of the corresponding abstract component
description. This implies descriptions should be deployed to be retrievable
by simple dereference of the relevant identifier."

That said, we might take this as good practice with respect to the
relationship between a identifier used to denote any particular thing... and
a description (or representation) of that particular thing - which does begs
the question of whether descriptions is a form of representation.

> The TAG is working on a human-centric namespace name format. This 
> format and the related fragment identifier syntax are not sufficiently 
> advanced in the W3C process for the TAG to recommend that a working 
> group use them. The abstract component identifiers as defined in a 
> particular language, and the relationship to the description language 
> syntax, the fragment identifier syntax, the use of a namespace name 
> document, and the namespace name document fragment identifier syntax 
> is not clear at this time. The TAG expects to continue work on this area.

I think we should simply delete this paragraph! IMO it conflates
namespaceDocument-6 with abstractComponentRefs-37. It expresses a
human-centric bias on namespace document format that I do not believe is a
concensus position of the TAG. The last couple of sentences catalog a whole
bunch of contingent work that we simply haven't done... I'd just loose it.

> As for the particulars of the syntax, the TAG does not wish to 
> delve deeply into syntax design of the WSD fragment identifier 
> syntax, believing that the WSD WG is better qualified for such 
> activities. A number of TAG members did have some particular 
> comments on URI syntax construction. The use of parenthesis 
> should be avoided, and the use of periods "." as a separator 
> seems useful. Effectively, the TAG offers a syntax that is very 
> close to the last syntax produced by the Jonathan Marsh but 
> using fragment identifier separators. To be clear, it is some 
> TAG members that offer this opinion on the specific syntax 
> rather than TAG consensus. The option that some TAG members 
> support is option #1A.

Editorials:

"...is very close to the last syntax produced by the Jonathan Marsh..."
should be supported with a reference (to the last syntax...).

"...but using fragment identifier separators." I don't know what fragment
identfier seperators are... lots of #'s... I don't think so.

"...option #1A." is a dangling reference.  Should probably make option
numbers h2-h3 headings. I think this is a reference to Section 3.1 option
#1... but there are several option #1's and there is nothing labelled
"option #1A".

> The TAG is planning on being available for liaison meetings in the Tech 
> plenary 2004 week. Further discussion of this issue, and others, with 
> the WSD WG is possible should the WSD WG desire.

This will date very quickly, finding content is probably not the best
vehicle for this invitation/offer.

> 2 Problem analysis

Are these requirements from the WSDL folks?
If so we should reference their statement of their own requirements.

> 2.1 Requirements
> - It must be possible to identify each abstract component in a 
>   WSDL vocabulary with a URI.

Ok...

>
> - It should be simple to create and use the URI.

Ok...

> - It should be possible to retrieve a namespace name document given an 
>   astract component reference if the namespace name is used as part 
>   of the URI.

It should be possibe to retrieve a description of the component given a
component reference. I'm less convinced of the need to tangle this up with
namespace documents - although a namespace document may (but not
necessarily) be a source of such a description (assuming WSDL is an
acceptable format for a namespace document).

> - It should be possible to use relative URIs for the abstract components

Why is this a requirement? Might be a would be nice... but it would make
component names based on URNs inadmissable as a solution (unless scoped down
to URI schemes that support relative forms... in which case it seems like a
requirement that is trivially met).

> - It should be possible to extract the type information from the URI. 
>   There has been some discussion that embedding metadata, particularly 
>   the type of the refered to thing, is a bad idea. There is an open TAG 
>   issue on this, metadata in URI[14]. It might be useful to provide
guidance, 
>   either specific to this issue or in issue 14, as to when metadata such 
>   as types either should or should not be put into URIs.

Ok.... I'm delinquent here and have work to do to revise the metadataInURI
finding. On this topic the concensus that I think I'm hearing is that its ok
to embed immutable identifying properties/facits of the identified thing in
the identifier. It's less ok to look at something that looks like say an
identifier that 'looks' like it might denote a particular WSDL portType or
messagePart without knowing (by means unspecified) that the identifier does
infact denote an abstract WSDL component. So... in a nutshell it's ok to put
it (*static* metadata) in, but you need to be more confident of what you're
dealing with to take it out.

> - It should be able to identify WSDL extensions, ala soap:binding, 
>   soap:operation, soap:address, soap:body, soap:action, soap:fault, 
>   soap:header, soap:headerfault, http:address, http:binding, 
>   http:urlEncoded, http:urlReplacement, mime:content, etc.

ie. the abstract component type system needs to extensible [I think is what
you're saying].

Editorial:

The discussion of options in section 3 seems a bit loose and uncertain in
places.

Throughout section 3 in the pro/cons section there are mentions of "Type
is/is not apparent". Needs to be clear that we're talking about the type of
abstract component(port, portType, operation, message, message part...),
rather than eg. schema data type.

Several cons state: "URIs aren't guarateed to be unique." This could mean
that there are multiple URI that denote the same component, or that several
components might be denoted by the same URI.

3.5... can you justify why ' The "." separator is better suited than "/"
within parens due to parser implementation issues'?



> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: 16 October 2003 21:29
> To: www-tag@w3.org
> Subject: Draft Finding on AbstractComponentRefs-37 issue
> 
> 
> I attach the html.  Hopefully soon I will get my cvs access going.
> 
> I thought that there were some general web architecture 
> practices that should be described in the finding and also be 
> "liftable" into the web arch document.  I've put these into 
> the TAG recommendation section.  Ian, you can probably copy 
> the first 3 paragraphs and the good practices into the web 
> arch doc, and optionally the 4th paragraph, from the TAG Rec section.
> 
> Cheers,
> Dave
>

Received on Wednesday, 29 October 2003 11:06:08 UTC