Re: Comments on Conformance section (part 1)

Hi Yves, Christian, all,

Yves Savourel wrote:
> Hi Felix, Christian, all
> 
> Here are some comments on part of the Conformance section
> (http://www.w3.org/International/its/itstagset/itstagset.html#conformance)
> 
> 
> ===1: First paragraph of section 4.1.
> "They don't concern" should be "They do not concern".

Done.

> 
> 
> ===2: Clause 1-1:
> "(e.g. the head element in HTML)." Maybe XHTML instead of HTML?

Done.

> 
> 
> ===3: Clause 1-2:
> "All data category attributes must be declared at all elements which are part of the existing or new schema."
> 
> A) The link of "data category attributes" seems to be broken (in all occurences)
> 
> B) I'm not sure what "data category attributes" are. It sounds like something such as its:locInfoPointer would be such thing, but
> that is an attribute not used locally. I understand this means all ITS attributes one can use locally. Maybe there is a way to
> articulate this better?


I will change that to "all local attributes", and have a SHOULD here.
(reply to D) ).

> 
> C) It seems too much to force *all* data categories to be declared.


I was trying to keep it simple: "If you want to use ITS markup
declarations, use them all". If people want to use only a subset of the
markup declarations, they will have to change the ITS schemas we define
by hand.

> 
> D) I would disagree with forcing to put ITS attributes in *all* elements.

I agree with your disagreement.

 This for several reasons:
> 
> 	D.1) It's OK most of the time for the article-type XML documents (DITA, DocBook, XHTML, etc.) but it makes less sense in
> many of the resource/data-oriented XML documents, where large sets of elements may have nothing to do ever with text data.
> 
> 	D.2) It makes no sense for some of the data category when the elements are empty... For example allowing almost any ITS in
> XHTML <br/> is meaningless: <br its:term='yes'/> means nothing, why forcing that to be valid?
> 
> 	D.3) Some data categories may be already defined in the host format (like translate in DITA, or bidi and ruby in XHTML). It
> would probably be not a good idea to encourage using ITS markup over the native one.
> 
> So it may be *convenient* (in some cases) to declare them on all elements, but one should not have to to be conform.
> 
> 
> E) I would replace "part of the existing or new schema." by "part of the schema.". 'existing or new' does not add anything to this
> clause, and the paragraph "Who uses this product" covers this 'existing or new' aspect for all clauses.

done.

> 
> 
> ===4: Clause 1-3:
> "The ruby element must be declared as an inline element (the definition of inline depends on the existing or new schema.)"
> 
> A) This look a bit strange. Its says basically: "The ruby element must be declared as a specific type of element, and you will know
> what that specific type of element is depending on your schema." If we don't say what an inline element is exactly we might as well
> not say anything.
> Maybe something like: "The ruby element must be declared in elements that have text content." or something better?

"Inline" is motivated by the definition of ruby markup in
http://www.w3.org/TR/ruby . Maybe I should refer to that?

> 
> 
> ===5: Clause 1-4:
> "The span element may be declared as an inline element (the definition of inline depends on the existing or new schema.)."
> 
> A) Same as for clause 1-3.
> 
> 
> ===6: Clause 1-5:
> "The declarations of general datatypes should be taken into account."
> 
> A) The link to "declarations of general datatypes" is broken. So I have no idea what it means exactly :)

this will change with the new schema design, so I'll delete the
conformance clause.

> 
> 
> ===7: Paragraph 2 after the clauses:
> 
> "Since the definitions in are ...": "in" what?

This was again a broken link. I changed it to "Since the ITS markup
declarations ..."

> 
> "It depends on the design of the existing or new schema (e.g. whether it already has a customization layer which uses parameter
> entities) what is appropriate." sounds strange to me.
> 
> Maybe, instead:
> 
> "The appropriate steps to integrate ITS into a schema depend on the design of this schema (e.g. whether it already has a
> customization layer which uses parameter entities)."

Done.

> 
> And for the part: "The ITS schemas in the format of XML DTD, XML Schema and RELAX NG in Appendix A: Schemas for ITS are only
> informative examples, it is not not feasible to integrate them into every existing or new schema."
> 
> I would drop ", it is not not feasible to integrate them into every existing or new schema". Beacuase it does not really add any
> usefull information.

Done.

> 
> ...and there is the discussion about whether the schema are normative or not obvioulsy...


yes. Yves, Christian, all, what do you think, given the thread between
Sebastian and me?

> 
> 
> ===8: Last paragraph of section 4.1:
> 
> I would drop: "ITS markup declarations are a set of elements and attributes, that have been designed using state of the art
> knowledge about internationalization and localization needs.". It sounds very pretencious :)

yes :) . Done

> 
> I would drop: "Since the goal of the ITS Working Group is to deliver one set of declarations, the conformance levels defined in this
> section do not allow an existing or new schema to use only parts of the ITS markup declarations. However, this concerns only the ITS
> markup declarations in a schema." Since I don't agree that all data categories must be permited to have a conformant ITS markup.

Just to make clear: I'm only talking about "ITS markup *declarations*",
not the markup in instances or processing expectations. Background for
my proposal to enforce all declarations: We are chartered to produce
*one* tag set. I'm not sure if allowing for fractioned ITS sub schemas
would be a response to that requirement.


> 
> I would probably drop: "As for the interpretation of ITS markup and the respective data categories, the product and conformance
> criteria defined in Section 4.2: Conformance Type 2: Processing Expectations for ITS Markup are relevant." Because the next section
> is just after. I guess that could saty for a transition (but it's a specification not a dissertation, do we have to have
> transitions? :)


Dropped.


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