Checking best practices related to ITS data cats

The editing process has caused me to think more carefully about the text in
the BPs, and I wanted to run through a checklist to check we have everything
right.  I'd like to discuss this at tomorrow's telecon.

These are the things I think you are likely to want to do wrt ITS markup:

A.	add local ITS markup where equivalent markup doesn't already exist,
eg. its:translate etc 
	- this only applies when you can add new features to a schema


B.	provide global rules for *content authors* to override default
behaviour OR specify information
	- particularly useful for what I will call here 'author-definable
semantics', a classic example being a span element with a class name, as in
microformats - this sets up a context which a schema author has not planned
for
	- the 'specify information' aspect may only apply to locnotes, where
a schema developer can decide to store all notes in the global rules rather
than the content, if they want
	- this can be added to a new schema, a schema to which new ITS local
markup is being added, or to an existing schema 


C.	document behaviour of markup in a separate ITS Rules document 
	- Documenting default behaviour typically has two sides to it: 
	(1) describing the equivalence between attributes or elements and
ITS local markup, eg. mytranslate == its:translate, and 
	(2) defining default values for general markup, eg. all alt
attributes contain text that should be translated.

Not all of the above scenarios are relevant to all data categories.

In the current document, documentation in a separate ITS Rules file is
typically described under the heading "How to handle legacy markup" (meaning
situations where you can't change the schema), however there are situations,
in my mind, where documentation needs to be applied to new or modified
schemas (eg. default translate assignments, or situations where people like
DITA don't use the its prefix when adding local markup, or situations where
its markup is added for some features, but legacy markup is preserved for
other features).  For these reasons, I think that the title "How to handle
legacy markup" should be changed to something like "Documenting default
behaviour".

Looking at the current best practices, here is what I think is included or
missing:


BP1: language
A	covered by xml:lang (ok as written)

B	although we should strongly recommend the use of xml:lang, rather
than any other approach, there may be situations where author-modifiable
global rules could be useful, eg. we currently say "one cannot specify
different languages for an attribute and the element content. ITS does not
provide a remedy for this." but it it possible to do so using langRule (if
the schema author makes that available)

C1	ok as written (no need to document xml:lang use because should be
understood; need to document anything else)

C2	I think that if a format is such that the language of a given set of
attributes or elements will always be in a given language, then you ought to
document that, eg. for bilingual dictionary format - this is not only for
legacy formats - this is not currently stated



BP2: direction
A	ok as written

B	not covered, but unlikely that this is sensible, since dedicated
markup should be used for directionality - there should probably, however,
be a note to this effect

C1	ok as written

C2	because only dedicated markup should be used, this should be either
its:dir or the equivalence described by C1, so it is good to avoid
describing general defaults here 



BP3
n/a



BP4 & BP5: translate
A	covered in BP5

B	covered in BP5

C1	covered in BP5

C2	covered in BP4



BP6: segmentation
A	n/a

B	not covered - is this an issue?  Are there author-definable
semantics that would make the global rules useful inside the document?

C1	no mention of equivalent non-its markup is made - is this ok?

C2	covered



BP7: ruby
A	covered, although not explicitly clear that children of its:ruby are
needed too

B	covered, though I think this is not appropriate in this case - ruby
markup should be dedicated markup - I suspect we should remove the relevant
paragraph

C1	covered

C2	because ruby should be associated with dedicated markup, this should
not need elaboration



BP8: notes
A	covered

B	The ITS notes data category provides for note information to be
stored in the global rules, rather than integrated into or identified in the
content. This alternative implmentation strategy ought to be described a
little more clearly as an acceptable alternative to embedding notes in the
content - it's currently there, but not very clear.

C1	covered

C2	I think we ought to have another BP here similar to BP10 for terms,
since presumably existing 



BP9: n/a



BP10 & BP11: terms
A	covered in BP11

B	covered in BP11, but I wonder whether you would need this if you
have implemented A - presumably this is for situations where legacy stuff is
hanging around?  Ie. I think 'it is also recommended...' straight after the
'use its:term' paras is misleading without further expansion.

C1	covered in BP10, though terminforef only mentioned in passing, other
markup not mentioned at all - also BP10 doesn't frame this as being for
dealing with legacy (or non-ITS) markup; it should'nt be needed if you
applied its:term etc. - I'm also not sure why this is a separate BP - it
doesn't seem to be the same type of separation as we have for translate

C2	see C1


		
BP14: span




============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/International/
http://rishida.net/blog/
http://rishida.net/

 
 

> -----Original Message-----
> From: Yves Savourel [mailto:yves@opentag.com]
> Sent: 24 October 2007 19:56
> To: 'Richard Ishida'
> Subject: dirRule, etc.
> 
> Hi Richard,
> 
> After some more thinking:
> 
> === For BP2:
> 
> I think in BP2 what is missing is just a para like in some other BP 
> where we set the case for overriding
> 
> "It is also recommended that you define the its:rules element in your 
> schema, for example in a header if there is one, and within that, the 
> its:dirRule element. Content authors can then use these elements to 
> globally change the directionality information on elements and 
> attributes."
> 
> 
> 
> 
> === For BP 8:
> 
> We have:
> 
> "It is also recommended to define the its:rules element in your 
> schema, for example in a header if there is one. The its:rules element 
> provides access to the its:locNoteRule element which can be used to 
> specify localization-related notes globally."
> 
> I think it misses (in addition to the re-wording you'll do) a sentence 
> about the fact that these global rules can be used not only to specify 
> things globally, but also to alter previous rules, or default.
> 
> The same goes for BP2 and probably other BPs.
> 
> So to BP 2 I would add something like: "These elements can also be 
> used to modify what markup is associated with directionality 
> information." (or something like that)
> 
> 
> just some thoughts
> -yves
>

Received on Tuesday, 30 October 2007 18:24:38 UTC