Re: Comments on Conformance section (part 2)

Hi Yves, Christian, all,


I am going through the changes and implementing the ones I don't see an
issues. Christian, all, if you don't agree: please shout.


Yves Savourel wrote:
> Hi Felix, Christian, all,
> 
> Here are more notes on the specifoications:
> 
> 
> ===1: Paragraph 1 of section 4.2:
> 
> I would replace "Description: processing expectations ..." by "Description: The processing expectations ..."

Done.

> 
> I would replace "existing or new schema" by just "schema" (everywhere!)

Done in the whole draft.

> 
> 
> 
> ===2: Paragraph 2 of section 4.2:
> 
> I would replace "...type: the processing ..." by "...type: The processing ..." 
> 
> I would replace "In addition to selection related processing expectation, an additional set of expecations is described for the ruby
> data category and directionality data category, by normatively referencing external specifications."
> 
> By
> 
> "In addition, a set of processing expecations specific to the ruby data category and the directionality data category, refers to
> external specifications."

Done, except "refer" instead of "refers".

> 
> 
> ===3: Paragraph 3 of section 4.2:
> 
> I would replace "...product:. Processing..." by "...product: Processing..." (delete the .)

Done.

> 
> I would replace "...which needs to process the nodes (element and attribute nodes) which are captured by a data category for
> internationalization and localization."
> 
> By
> 
> ...which needs to process for internationalization or localization the element or attribute nodes captured by a data category."

Done.

> 
> 
> ===4: Clauses of section 4.2:
> 
> A) A space is missing in clause 2-1: -> "oneselection"

Done.

> 
> B) Clause 2-3 and 2-1 seems contradictory: It seems one one cannot both support only one type of selection and take "Section 5.2:
> Precedence between Selections" into account as a whole.

yes, that is contradictory.

> 
> Maybe saying: "2-3: If an application claims to process ITS markup for a given data category, it must take the precedence
> definitions for selections defined in Section 5.2: Precedence between Selections into account, for the type of selection it
> processes." (?)

Done. Btw., do we need to make this clear? I.e.:
- global ITS: take 2,3 and 4 into account
- local ITS: take 1 and 4 into account
- global and local: take all into account


> 
> ===5: paragraph 2 after the clauses:
> 
> I would replace:
> 
> ""Applications" which are conform to the clauses above can be for example ITS markup..."
> 
> By:
> 
> "Applications which are conform to the clauses above can be, for example: ITS markup..."
> 
> (removing quotes, adding comman, and colon)

Done. (not marked with change markup - too many colors ...)

> 
> Typo: "They only common..." should be "Their only common..."

Done. (not marked with change markup - too many colors ...)

> 
> 
> ===6: Last paragraph of section 4.2:
> 
> I wonder if this paragraph is not more confusing than helping. It just repeats what some of the clauses say. I would think of
> dropping it.

Done.

> 
> Layout: the paragraphs below the "Examples" parts in both section 4.1 and 4.2 are indented. I assume it's by design. But it looks a
> bit strange since the first paragraph in each case is not indented.

that is a stylesheet problem. I'll work on that.

> 
> 
> ===7: Second bullet of section 5.1:
> 
> "...attributes , which..." should be:
> "...attributes, which..."

Done. (not marked with change markup - too many colors ...)

> 
> 
> ===8: Section 5.1.1, Title and first paragrap:
> 
> Shouldn't 'based' be capitalized in "Global, Rule-based Selection"?
> (not sure, just a question).

I don't think it should be capitalized, but I'm not sure either ...

> 
> "more rule elements . " should be:
> "more rule elements. "

Done.

> 
> "an locInfoPointer attribute can be used.." should be:
> "an its:locInfoPointer attribute can be used."

Done.

> 
> In "using the rules element" 'rules' should be bolded/linked to ist definition.

that is still a stylesheet problem throughout the whole document, I'm
working on that.

> 
> In "a mandatory select attribute." 'select' should be 'selector' and bolded/linked to the selector definition (like in other
> paragarphs). Same for its:locInfo, its:locInfoPointer, translate, etc.
> 
> Paragraph under the editor note: The link for 'selector' is broken.

The broken links are all due to the stylesheet problems mentioned above.

> 
> I would rewrite: 
> "with "/", that is, it..." by:
> "with "/". That is, it..."

Done. (not marked with change markup - too many colors ...)

> 
> === 9: Example 8:
> 
> It look strange to mix delcaration for TEI and DocBook in the same rules element.
> I would rewrite it:
> 
> <!-- Definitions for TEI -->
> <its:rules xmlns="http://www.w3.org/2005/11/its">
>  <its:ns its:prefix="tei" its:uri="http://www.tei-c.org/ns/1.0"/>
>  <termRule its:selector="//tei:term"/>
> </its:rules>
> 
> <!-- Definitions for DocBook -->
> <its:rules xmlns="http://www.w3.org/2005/11/its">
>  <termRule its:selector="//qterm"/>
> </its:rules>


Done.

> 
> About the note just below example 8:
> 
> "...element is motivated by [Schematron] and compliant..." Is *motivated* the right word? It's inspired, based-on, but motivated?...
> Maybe our English native speakers can have this worded differently?

changed this to "inspired".

> 
> 
> Paragraph: "Having its-global as the entry point of the schema serves as a wrapper schema for an external rules file." 
> 
> What is a "wrapper schema"? This sentence does not seem to add useful info. I would drop it (but maybe I just don't understand it).

Dropped it, I think it is not necessary.

> 
> Questions about "Instance Document":
> 
> - is it "Instance Document" or "Document Instance"? (searching on the W3C web site I see 615 occurences of "document instance" and
> 343 for "instance document". And I can't quite see the difference.

My "XML" half-native speaker feelings says me it is "instance document".

> 
> - Do we need to say that all the time? Didn't we use this as opposed to "schema document"? But now the distinction is gone. Why do
> we keep saying it? Wouldn't just using "document" be better?

I got rid of most occurences of "instance document" in the draft.

> 
> 
> ===9: paragraph 2 of section 5.1.1:
> 
> I would drop the first sentence: "Attributes which add information to the selected nodes are available for each data category. "
> because that is what the paragraph just above already says.

It did not say "for each". I am trying to make the point: "All data
categories allow for adding information; some allow also for pointing to
existing information".

> 
> I would split the first paragraph after "For example" and make the end one example, and the second paragraph a second example.

Sorry, I don't understand the proposal ...

> 
> ===10: Example 9:
> 
> "its:translate="no" at the head element means that the textual content of this element, including child elements and attributes,
> should not be translated. its:translate="yes" at the body element means that the textual content of this element, including child
> elements, but excluding attributes should be translated."
> 
> Wow... This is wrong.
> Since when the default selection changes depending on the value of its:translate???
> The fact the attributes are not translatable is not because of the selection for translate, but because the translate selection does
> not affect their default state at all. its:translate has no effect on attributes, whether it's its:translate yes or no.
> 
> I would re-phrase this with something like:
> 
> "its:translate="no" at the head element means that the textual content of this element, including child elements, should not be
> translated. its:translate="yes" at the body element means that the textual content of this element, including child elements, should
> be translated. Attribute values of the selected elements or their children's are not affected by (a local?) its:translate. By
> default they are not translatable."

yes, that sounds much better. Done.

> 
> ===11: paragraph below example 9:
> 
> "The span element " span should be bolded/linked to its definition.

Again stylesheet problem ...

> 
> 
> That's all for now.
> -yves
>