Re: Comments on http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/

Graham Klyne <GK-lists@ninebynine.org> wrote:

>>> any new attribute vocabularies defined MUST conform to the RDF schema in
>>> appendices B and C.
>> I don't believe RDF schema supplies any definition of conformance, so you
>> will have to explain what you mean by conformance here. How do I make a
>> vocabulary that conforms to your schema?
> 
> Good catch!  I think it should say:
> 
>  CC/PP applications are not required to support features described in the
>  appendices, but any new attribute vocabularies defined MUST be based on RDF
>  classes and properties defined by the RDF schema in appendix B (new CC/PP
>  attributes sub-properties of ccpp:Attribute, new client components based on
>  ccpp:Component, etc.).

How? Where? See below...

>> You also use rdf:about attributes with relative URIs that reference other
>> documents. (like rdf:about="xxx") I believe this is a clear mistake. These
>> should be replaced with either rdf:ID or rdf:about="#xxx".
> I think this is one of the difficulties of documenting an RDF-based
> format.  If the examples are constructed as perfectly usable RDF I believe
> they become difficult to read.  So I was trying to use a name to stand in
> for a full URI, which I felt to be easier to read;  also it corresponds
> directly with the "graph" example it purports to represent.

A # or capital letters make it difficult to read? I doubt so. Worse, if you
do not fix this, it will encourage people to read the spec to pick poor URIs
for the items in their documents. This will be a large mistake, since they
will be mostly incompatible with other systems.

> Also, I think using the '#fragment' syntax is confusing for a different
> reason:  when used in a protocol element (as is the intent for CC/PP), it
> is not obviously contained within a document having a base URI against
> which to resolve the relative form.  Typically these would be full absolute
> URIs.

Exactly, which is why it is important to use the #fragment syntax. Were you
not to use this syntax, you would be referencing another file in the same
directory. While this makes sense for HTTP GET, as you point out this will
be rarely used for CC/PP. (Even in HTTP GET, it requires that you create
these other documents, or at least reserve them, which seems a bit silly.)
However, all URI protocols (IIRC, otherwise most all) require the use of
fragment identifiers. For example, RDF in this email message could be
referenced by the mid:B6F10176.852A%aswartz@upclink.com#fragment URI.

Even if no URI exists for the transaction (which seems more than likely in
many situations) at least the fragments are internally consistent, even if
they are not accessible using absolute URIs, they do make sense, and a
processor can make up a base URI for them.

> (There's also a note from Ralph Swick about the fact that it's not always
> obvious how fragment addressing should work -- something I hope we'll clear
> up in the RDF review WG.)

I believe I address this later...

> Maybe I should italicize these names, to signal that they're not straight
> URIs?

No, I think you should use real URIs, so as to demonstrate the _correct_ way
of doing things. Don't you agree that it's worth adding one character to
ensure compliance? RDF isn't pretty to begin with...

>> In Figure 2-2b (and other examples), you show an rdf:type property with a
>> value of "BrowserUA" (and other similar values). This seems like a mistake,
>> since such a value would mean that the type of the property would change
>> every time the document was parsed by an RDF parser. Surely this is not what
>> you want. It seems like it would be more effective if you used the typedElt
>> syntax, like:
>> 
>> <ccpp:component>
>>   <BrowserUA rdf:about="#xxx">
>>      <!-- ... -->
>>   </BrowserUA>
>> </ccpp:component>
> This is a similar situation as above.  These are placeholders for URIs
> rather than actual URIs.

Hmmph. Then use an example namespace (under example.org) and follow my
suggestion.

> (Sometimes, I find the
> HTML tools available for this kind of document editing are really primitive.)

You're not alone. I assume you're a member of W3C spec-prod?

>> Figure 2-12 is a broken image (404).
> Hmmm... it worked for me.

Not for me. Perhaps it's a badly formed image, or in some odd format... I'm
running MacIE 5.0.

Are we talking about the same document?

>>> RDF Model and Syntax specification [3] defines two ways to name RDF
>>> resources, namely "ID" and "about". RDF resources named by "about" are fully
>>> identified, whereas those named by "ID" can not be referenced from outside
>>> the containing document, unless some additional information is available
>>> that allows the full (absolute) base URI to be determined. The RDF
>>> specification is not currently clear about how a base URI should be
>>> determined [34].
>> Actually, I think you misunderstood Ralph's letter. RDF clearly defines how
>> to determine the absolute URI, and how a base URI should be determined is
>> clear. The problem is that there is no mapping from a fragment identifier to
>> the ID attribute in RDF. However, most people assume this mapping, although
>> it is not officially specified. Especially since the spec refers to the
>> value of ID attributes using fragment identifiers itself! So, while you may
>> continue to require that the about attribute is used, please correct your
>> statements about the RDF spec.
> I quote from Ralph's note:
> 
> [[[
> In fact, the RDF Model and Syntax specification does not tell you
> how to construct a full URI for the resource named by an ID or bagID.
> The resources are addressable at best only locally within the
> same RDF/XML expression.
> ]]]

While this is not the time or place to argue about this, I'm almost certain
the spec does define this, and it is not an issue. Especially since the
specification defines that URIs should be resolved following the URI spec,
and it either specifies or implies that ID can be referenced using fragment
notation, the only logical conclusion is that the resolved fragment is the
correct URI for the IDed resource.

>> With the proxy chaining described in 3.2.1, how would an implementation find
>> the outmost layer in the chain? How should implementations deal with
>> nextProxy cycles, dead-ends etc. Perhaps you could provide an algorithm to
>> make this easier.
> The first in the chain is what you are given (either directly or by URI
> reference).

Where is this "given"? Or URI reference? I don't understand.

> Possibly, we should say that a proxy chain that loops or does not end with
> a client profile is an error.

I think this would be good.

>> Also, why do you make a separation between request profiles and proxy
>> profiles? It seems this just adds unnecessary bulk. It would make more sense
>> just to have chains of proxyProfiles pointing down towards the client.
> We went round this in the working group...  chaining the proxy profiles
> directly (remembering that the same profile may, in principle, describe
> several different proxies) runs the risk of aliasing causing a loop or
> indeterminacy in the proxy chain.
> 
> This structure also helps to separate the dynamic, per-request part of the
> profile structure from the static description of a proxy (though, as we
> found, that benefit is slightly illusory).

Ahh, I see.

>> In Figure 3-13b:
>>> <rdf:li>text/xml</rdf:li>
>> 
>> I remember some discussion about this, so maybe it's been decided, but why
>> don't you just use the content-type URIs and stick them in the schemas
>> section. It seems much simpler. The official URIs are:
>>     ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
>> as defined in ftp://ftp.isi.edu/in-notes/rfc2048.txt
>> 
>> (I keep track of this at: http://logicerror.com/contentType )
> 
> Ah, this can-of-worms ;-)
>
> As things stand, I do not believe that the assignment of URIs and hosting
> of these specs by ISI has the necessary expectation of stability to use
> these things as protocol elements.  However, there is a work in progress
> (or two) in the IETF to create a stable URI for these and other
> IANA-registered values.  So for now I think we're stuck with the
> text.  Later, I'd hope we can define the appropriate URI equivalences for
> this property.

I don't understand. These URIs work just fine, an RFC has clearly designated
them as appropriate, they are extremely unlikely to be used for anything
else. What's the problem? They are perfectly stable. Where is this legendary
instability?

>>> <rdf:li>http://example.org/example/XHTML-1.0</rdf:li>
>> 
>> Are you sure you don't mean:
>> 
>> <rdf:li rdf:resource="http://example.org/example/XHTML-1.0" />
>> 
>> These mean two totally different things. One is a string of characters, the
>> other is a URI. I'm pretty sure you mean to use a URI here.
> You may be right, but there was an issue I picked up that suggested that
> some URIs should be treated as literals rather than resources.  I'm not
> sure if it applies here.

I don't believe it does.

> I think this will need to be picked up later and revisited in the WG, or at
> least separately.

I believe this is an important issue to discuss.

>> With Figure B-3, the RDF spec recommends not using entities as you do for
>> your namespaces since they might be removed in a future version of XML.
> I've never spotted any such recommendation.  Can you give an exact
> citation, please?

I don't have access to the spec right now, so I can't quite exactly but a
grep for "future version" should find it.

>> Also, why do you declare your own ccpp:Resource? It doesn't seem you get any
>> benefit from that, but simply pollute the namespaces.
> The intent is to allow CC/PP profile structure to be distinguishable (by a
> schema-aware RDF processor) from other RDF it might be embedded in, or
> embedded in it.  For example, if future CC/PP attributes have arbitrary
> resource values, this may be needed to determine where the CC/PP profile
> ends and the attribute value begins.
> 
> I'm not sure what you mean by "pollute the namespace".

What I meant was that this will likely prevent the reuse of attributes from
other systems. Furthermore, to allow this reuse, new assertions will need to
be made (that these terms are subclasses of ccpp:Resource) "polluting the
namespace" with unnecessary information.

>> Also, you may not want to use rdf:ID in these schemas, unless you specify
>> the base URI since you'll effectively be defining all these terms with the
>> namespace of the specification itself!
> Er, no:  they'll be under the URI of the schema document, which is the
> intent here.

Then the base URI for these schemas should be specified.

>>>       A proxy profile has an arbitrary number of ccpp:proxy-behavior
>>>       properties, each of which indicates an individual
>>>       ccpp:Proxy-behavior value.
>> 
>> Actually, there is no proxy-behavior property. I believe you mean
>> proxyBehavior. BTW, why the inconsistent naming of that one property? --
>> you're right to be confused.
> 
> You're right, it should be proxyBehavior.  I thought it was quite
> consistent:  initial lowercase with "interCaps" for properties;  initial
> capital with hyphens for class names.
> 
> (The capitalization convention is as recommended by RDFM&S, appendix C.1)

Actually I believe that RDFM&S recommends the use of interCaps for classes,
also. This is what confused me, since I was not use to this new style and
thought of it as a typo.

>>> This is one of three properties to describe a proxy behavior.
>> This is unnecessary, and sort of limits extensibility. You can keep it in
>> the text, but you don't need it in the schema.
> I don't agree.  And why do you think it limits extensibility?

Because what happens if you add another property for proxy behavior? Or what
if someone else does?

> ....  This is used to
> add proxy behavior descriptions to a request profile received
> from a proxy or client system on the outbound side.
> etc.?

Don't you mean received by a proxy...?

>>> URIs and optional fragment identifiers
>> According to the URI spec, a "URI reference" includes a fragment identifier,
>> so I don't think you need to be so explicit about this.
> Ah, but... the intent was to avoid the namespace problem:  I say URI, not
> URI reference, with optional fragment identifier.  The intent was to avoid
> to avoid relative URIs, which are also allowed by URI reference.
> 
> Maybe I should be more direct and say "no relative URIs".

Yes, please. This is confusing and beating around the bush. Few are likely
to understand the subtlety unless you make it explicit.

>>> An attribute defined very broadly might be subject to different privacy or
>>> security concerns when applied in different circumstances. For example,
>>> having a text-to-voice capability on a mobile phone type of device might be
>>> a generally useful feature, but a similar feature in a PC might be
>>> indicative of a personal disability.
>> This doesn't make sense. It seems if anything, a specific attribute would be
>> more of a privacy concern. supportsScreenReader is a disability giveaway,
>> where as the broader textToSpeech is less revealing. Having well-defined
>> attributes is good practice, but the reasons provided should be sound.
> Hmmm... yes, sort of.  The intent here was that a broadly defined attribute
> was more likely to be widely used and subject to different privacy concerns
> under different circumstances, therefore more likely to be used in a way
> that makes unintended disclosure in conjunction when used in conjunction
> with other features

Hmm, I got the opposite impression.

> I suppose that, in a sense, we're guinea-pigs on this, as it's the first
> recommendation-track specification to be "pure" RDF.  Based on my
> experience, I think it would be great if N3 went to recommendation track so
> we could use it for normative specification work.

I've seen discussion of this on the RDF forums, and I highly recommend it.

>> Phew, all done. Does this mean I get to go in the acknowledgements section?
>> ;-)
> Well, I think definitely so.

Thanks! Would you mind linking it to http://www.aaronsw.com ? Just to
disambiguate, add semantics, etc.

> Thanks for the effort you've put in.

No problem. Thanks for working hard to provide such a "pure RDF" spec, as
you say. I think this is a great step forward, and I really support it. I
just wish it didn't seem so complicated (turning people off from RDF) but
perhaps a restructuring will help. Yet it certainly fares well against some
of the other "pure XML" specs.

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Thursday, 5 April 2001 01:32:13 UTC