Re: Need volunteer reviewers for RDFa Core 1.1 (pre-Last Call)

Shane,

  now that I've had a look into the ED, let me comment on the remaining things:

Monday 2010-10-18 23:02 Shane McCarron:
> On 10/11/2010 6:53 PM, Christoph LANGE wrote:
> > (!) A comment for future discussion: Would it make sense to specify an algorithm for "normalizing" a fragment?  I mean making it self-contained, so that it can be pasted somewhere else.
> 
> This is a good idea!  I am not going to try to come up with that for 
> last call.  However, see the new note in Sequence step 11.  Does this 
> start to get where you want to be?

Not quite yet.  I guess I put it in an ambiguous way, but by "fragment" I did not only refer to XML literals in the document, but to _any_ subtree whose root is an element.  Let me first comment on this far more general case, then on the specific step 11 note.

Assume the following document …

<doc xmlns="http://example.org/ns"
     prefix="foo: http://example.org/foo#">
  <para about="http://example.org/thing">
    This is <span rel="foo:rating" resource="http://example.org/cool">cool</span>
  </para>
</doc>

… being displayed in some browser, and suppose the user selects exactly the <span> element.  Then, my idea of normalization was that the browser should copy the following to the clipboard (as XML, not as text, of course, so I'm sure the @xmlns is already taken care of by some existing recommendation on how to process XML):

<span xmlns="http://example.org/ns"
  prefix="foo: http://example.org/foo#"
  about="http://example.org/thing"
  rel="foo:rating" resource="http://example.org/cool">cool</span>

Not sure how easy/hard it is to really thoroughly specify this for all cases.  For now I would consider such a specification optional, as this is a feature of a browser, whereas the RDFa Core spec so far mainly targets processors that yield RDF.  And IMHO it should all rather be a SHOULD than a MUST.

Now for the step 11 note: IIUC this is related to the new way of deep processing of XML literals.

> in order to maintain maximum portability of this literal, any children of the current node that are elements must have the current in scope profiles, default vocabulary, prefix mappings, and XML namespace declarations (if any) defined using their respective attributes.

IIUC by "children of the current node" you address rather the XML literal in the RDF output than the content of a *[@datatype="rdf:XMLLiteral"] element in the input document.  For the RDFa processor generating the RDF output, it is certainly a MUST to copy all profiles, prefix mappings, etc.  But the way it's put now, it could be misinterpreted as a requirement for the document author, i.e. that the document author MUST duplicate all prefixes etc. on all child elements of the XML literal.  That might actually make sense – when considering an RDFa processor whose development is stuck half way between 1.0 and 1.1.  The author could indeed help such a processor by duplicating all prefixes etc.  But that, of course, should only be a SHOULD requirement.

> > 4.2 RDFa Host Language Conformance
> >> If the Host Language uses XML Namespaces [XML-NAMES], the attributes in this specification should be incorporated in the namespace of the Host Language.
> > He had a discussion about that last week or so.  What does that mean?  Suppose the namespace of the host language is xmlns:h="http://host.org".  Should the RDFa attributes be used as<h:element h:about="URI"/>, or as<h:element about="URI"/>?  The latter (i.e. putting attributes into the empty namespace) is what, according to Toby, all currently existing host languages do.
> 
> Actually, this language is a mistake.  My mistake.  The intent of that 
> language, which I have used in lots of specifications, is that when the 
> attributes are used you don't need to use them with a prefix.  I have 
> fixed the text.

The fix looks good, but it does not yet cover my "favorite" case that the host language already has attributes in "no namespace" that conflict with the RDFa attributes.  I pray for the same as you said in your other mail, but still, with the ever-increasing set of RDFa attributes, I wouldn't assume collisions to be _so_ unlikely.  (I didn't do research (*) on how many potential host languages with such attributes exist, but I'm sure there are some.)  So, IMHO the requirements that "the attributes in this specification should be defined in 'no namespace'" and "if the Host Language has its own definition for any attribute …" should be extended by an additional item that, if the Host Language has its own definition for any such attribute and this definition is not consistent with the RDFa requirements, then the Host Language MAY integrate RDFa by using the RDFa attributes from the XHTML namespace.

(*) The only thing I know is that the Math WG has received the suggestion to support RDFa in MathML.  I'm not a member of that WG myself (but my advisor is), so I don't know exactly what they are going to do; personally I suppose that they are rather not going to support RDFa soon.  Therefore I haven't mentioned that case so far.  MathML has an @href attribute, with a similar semantics than XHTML, but as MathML already has a lot of its own means of annotating semantics, it's not clear, besides the question whether it makes sense to integrate RDFa at all, whether @href should be part of MathML+RDFa, or whether MathML+RDFa should put the RDFa attributes into their own namespace, i.e. the XHTML namespace.  (For now, take this as an example for a potential conflict.  About MathML+RDFa, the Math WG will probably make up their mind, and if they want it, they will approach you for sure.)

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701