Re: comments on nodeID in RDF/A

I think we agree: this proposal is legitimate but potentially confusing.
A better proposal would be desirable but any proposal has drawbacks.

I am coming round to yet-another-attribute myself. I think the main 
drawback of having too many obscure attributes for this stuff is a 
rubicon we've already crossed, and one that is not unfamiliar to HTML 
authors. Using either an xpointer syntax or a complex piece of syntax 
(i.e. my embedded element) has the same negative feature of being 
another thing to remember, and moreover has the negative thing of being 
a different class of thing to remember. e.g. suppose we had an attribute 
hNodeId, it's clearly not excellent, but ... it's only another attribute 
to add to the list of those attributes that many authors don't remember 
but need to look at the documentation for. Any different syntactic 
convention (whether the XPointer or the embedded element) would, for 
instance, be harder to include in the index of the xhtml2 rec, and hence 
harder to find, on the relatively rare occassions it got used.

Does XHTML2 make other uses of XPointer?
Is #node(a) useful in other contexts?

Jeremy



Mark Birbeck wrote:
> Jeremy,
> 
> I'm being a bit dim here, and I have not explained the XPointer proposal
> properly. You may find that it still doesn't 'work', but I should at least
> clarify how it was intended to work.
> 
> 
> 
>>I agree that there is nothing illegal about using #node(a) as 
>>a nodeID 
>>representation, but it does prevent the serialization of 
>>#node(a) as a 
>>URIref, and leads to potential confusion.
> 
> 
> The main thing is that the proposal was *not* supposed to generate URIrefs
> like this:
> 
>   http://www.example.org/mydoc.html#bnode(a)
> 
> I know that I endorsed this view when I said in my last mail:
> 
> 
>>>However, looking at it again I can see that there is no way 
>>>with this 
>>>approach to prevent the following (i.e., someone making statements 
>>>about your blank nodes):
>>>
>>>  <link about="http://example.com/your-doc#bnode(b)" ... />
> 
> 
> and must apologise, but I was a bit distracted when I saw your email, and
> replied too hastily. As it happens I spent a lot of time working on this
> 'solution' because I am well aware of the points you make about the
> distinction between a URIref and a blank node:
> 
> 
>>There has been lots 
>>of that on 
>>this issue; people find it hard to recognise that blank nodes 
>>and URIref 
>>nodes really are different.
> 
> 
> 
> Anyway, the whole point of the XPointer proposal was that the bnode scheme
> was actually 'traversed' or 'evaluated'. In other words, the GRDDLiser
> should evaluate the bnode scheme to find a sub-resource (in XPointer
> parlance), and so end up with a blank node identifier. The following is from
> section 3 of the XPointer Framework spec [1]:
> 
>   An XPointer processor takes as input an XML resource and a string
>   to be used as a pointer (for example, a fragment identifier, with
>   escaping reversed, taken from the URI reference that was used to
>   access the resource), attempts to evaluate the pointer with respect
>   to the resource, and produces as output an identification of
>   subresources, or one or more errors.
> 
> This means that the result of this:
> 
>   <link about="#bnode(a)" rel="foaf:knows" href="#bnode(b)" />
> 
> is *not* this:
> 
>   <http://www.example.org/mydoc.html#bnode(a)> foaf:knows
> <http://www.example.org/mydoc.html#bnode(b)>
> 
> but is intended to be this:
> 
>   _:a foaf:knows _:b
> 
> 
> The relevant section of RDF/A is at the end of 4.2.2:
> 
>   The bnode() Scheme Syntax is simply:
> 
>   [1]    BnodeSchemeData    ::=    (NCName) 
> 
>   An implementation of the bnode() scheme can return a [unique
>   anonymous ID] in any valid format that meets the requirements
>   of [RDF-CONCEPTS]. However, the same processor should always
>   return the same value for the same input. In addition, it is
>   not an error if the parameter does not refer to a value used
>   in a nodeID attribute.
> 
> The idea would be that a GRDDLiser could create unique identifiers using any
> technique it wanted to, but however it does it, it *must* do it, and keep
> them consistent. (I'm no longer so sure about errors, but that's a separate
> issue.)
> 
> My reading of both XPointer and [RDF-CONCEPTS] is that this is legitimate.
>>From the RDF point of view, we are not using a URIref, but the *result of
> traversing a URI* (a sub-resource, which in our case is a blank node). And
> from the point of view of XPointer you can do pretty much what you want with
> schemes, as described in section 1 of the XPointer Framework spec [1]:
> 
>   This specification does not constrain the types of applications
>   that utilize URI references to XML resources, nor does it constrain
>   or dictate the behavior of those applications once they locate the
>   desired information in those resources.
> 
> 
> I hope that clarifies at least the intention, and I apologise for the red
> herrings I've been throwing around.
> 
> Regards,
> 
> Mark
> 
> [1] http://www.w3.org/TR/xptr-framework/
> 
> 
> Mark Birbeck
> CEO
> x-port.net Ltd.
> 
> e: Mark.Birbeck@x-port.net
> t: +44 (0) 20 7689 9232
> w: http://www.formsPlayer.com/
> 
> Download our XForms processor from
> http://www.formsPlayer.com/
> 
> 
> 
>

Received on Tuesday, 26 October 2004 13:14:27 UTC