Re: Updated RDFa 1.1 Core editor's draft

Grant,

it is too early in the morning for me to look at the details... but it would be good if, in case you detect discrepancies, you could provide us test csses. Ie, small rdfa code with the rdf triples that, in your analyis, should be generated by the current algorithm. It would greatly facilitate the discussion...

Thanks!

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



On 8 Apr 2012, at 00:25, "Grant Robertson" <grantsr@gmail.com> wrote:

> The scope of this discussion is the RDFa Core 1.1 Editor's Draft (at
> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html), Section
> 7.5, Steps 5 & 6. 
> 
> Because [typed resource] is only a concern when @typeof exists, for the
> purposes of this discussion, assume @typeof exists in the element currently
> being processed.
> 
> For the purposes of this discussion I want to make the following
> distinctions:
> 
> base (without brackets) is the IRI of the document containing the markup
> being processed.
> <base> is the element that can set a default value to be used instead of
> base.
> *<base> is that value that is specified in <base>.
> [base] is a variable within processing software. 
> *[base] is the value of [base].
> 
> Curly braces mean the item inside exists within the current scope of
> discussion. For instance, {@about} means the @about attribute is present
> within the element being processed.
> 
> So, within our processing software...
> 
> If {<base>} then [base] = *<base>  else  [base] = base
> 
> (I know, saying it out loud sounds ludicrous. It violates all rules of good
> technical writing. But it is concise in plain text and appropriate for this
> audience.)
> 
> Additionally, when I say something "can be set to [base]" what I really mean
> is that it is possible for the processor to arrive at a step wherein the
> processor would possibly set a variable to the value the processor has
> stored in [base]. This is different from merely allowing a specific string
> of text (the IRI of the document) as an allowed value for a particular
> variable, [base]. In the context of the specification document: when I say
> something "can be set to *[base]" it means that the algorithm logic can
> arrive at the statement in the specification that says, "if the element is
> the root element of the document, then act as if there is an empty @about
> present, and process it according to the rule for @about, above;" because
> the end result of that statement is that the variable in question gets set
> to *[base].
> 
> (Personally, I think that statement is excessively wordy and indirect. I
> think it that, once it has been established that [base] == (base or *<base>)
> then you can just go straight to saying, "if in <root> then use *[base]"
> which is far more direct and compact.)
> 
> 
> ===============================
> So, now to my discussion:
> ===============================
> 
> I am concerned that there is still a difference between the results of Step
> 5.1 and the results of Step 6 as far as the the possibility of assigning
> *[base] to [typed resorce] or [current object resource], in the narrow
> situation wherein @typeof exists in the root element.
> 
> In Step 5.1, in the first half, the statement in question (the "if element
> is the root element..." statement) is directly under and therefore grouped
> together WITH the @about statement. It is essentially treated as an
> alternate means to set the value of *@about. This exact sequence of these
> two statements is repeated in the second half of Step 5.1. This latter means
> it is possible to reach the "if element is the root element..." statement
> when setting the value of [typed resource]. In other words [typed resource]
> could be set to *[base]. 
> 
> In Step 5.2, although separated in the text of the draft specification, the
> statements setting [new subject] to *@about or *[base] still come BEFORE the
> statement setting [typed resource] = [new subject]. Therefore it is still
> possible for [typed resrouce] to be set to *[base]. 
> 
> However, in Step 6, [typed resource] is set to [new subject] DIRECTLY AFTER
> the statement setting [new subject] = *@about. Only AFTER that do we reach
> the "if element is the root element..." statement. This means that, in Step
> 6, there is no possibility for [typed resource] to be set to *[base]. 
> 
> Now, I realize that this slight difference is entirely moot unless we are in
> the root element of the document. However, unless this behavior was the
> intention of the Working Group then I propose the following change to the
> draft specification:
> 
> In the first half of Step 6, move the "if the element is the root element
> ..." statement up two lines so that it is right after the "by using the
> resource from @about ..." statement and right BEFORE the "if the @typeof
> attribute is present, set typed resource to new subject" statement.
> 
> This will cause the behavior of when [typed resource] is set to *[base] to
> be equivalent across the board.
> 
> 
> Grant S. Robertson
> www.demml.org
> www.ideationizing.com
> 
> 
>> -----Original Message-----
>> From: Ivan Herman [mailto:ivan@w3.org] 
> 
>>> C.2.c) Also, - when in "Special Property Mode" - it is now possible 
>>> for [typed resource] to be set to [base], which is impossible in 
>>> "{@rel | @rev} Mode." Is this the intention? What would be 
>> the purpose of this difference?
>>> 
>> 
>> I am not sure what you mean. In both cases the value of 
>> @about is done through the CURIE and IRI processing, which 
>> may include base
> 
>

Received on Sunday, 8 April 2012 05:04:37 UTC