Re: Updated proposal for GL 1.3 L1 SC2

On Tue, 31 May 2005 Becky_Gibson@notesdev.ibm.com wrote:

>
> For HTML, this is the case where <strong> or <em> or font size or style is
> used to add additional meaning to the content.  The <strong> and <em>
> elements are not considered "structural" markup which is why we removed
> the word structural from the beginning of this SC.

Why aren't they considered structural? I could simply say they represent
inline structure. An element doesn't have to correspond to whitespace in
typeset output to be considered structural. >
> To help clarify that this SC is not about structural semantics we have
> modified the proposal to use "document semantics" which is considered to
> be an understood term in the industry.

And if the Web content is not a "document" what happens to the proposal?
Applications and user interfaces are a good example here. Also, "document
semantics", were it to be used, would require a definition. We can't rely
on a term's being "accepted in the industry" as an excuse for not defining
it, especially if it is to be used for conformance purposes.

>
> While we didn't specifically address this in our meeting,  via email we
> agreed that we could leave out the phrase,  "to the extent possible". But,
> do the issues raised concerning testability still exist even with that
> phrase missing? Joe did have specific reasons for including it in his
> original proposal [2].
>

Yes, I think all the testability and vagueness problems remain in the
modified proposal and would suggest deleting it.

The main unaddressed problem with guideline 1.3 is its interaction with
the baseline. To the extent that guideline 1.3 is independent of the
baseline, it operates as a constraint on acceptable baseline technologies:
only a combination of technologies can be used that allows 1.3 to be
satisfied. Yet, if guideline 1.3 is not relative to the baseline, the
question remains of how much structure is adequate, and what semantics
need to be represented.

Suppose there is a "concept code" markup language for representing certain
types of content that would otherwise be expressed in natural language.
This is not hypothetical; active work is being carried out in this area.
If guideline 1.3 is independent of my baseline assumptions, then surely
one can argue that, there being a markup language for it, I am obliged to
represent relevant parts of my content in concept notation, at level 1 -
not a desirable result from the point of view of the three-level
conformance structure. Or on the other hand, do we interpret "document
semantics" as allowing me to choose the markup language or coding that
yields minimal semantics and to use that as my baseline?

Suggested solution:

1. Make guideline 1.3 relative to the baseline. This may already be
achieved by putting "standard/supported" language into the definition of
"programmatically determined", but it may also need to be called out
explicitly in the document. We need to clarify that guideline 1.3 only
requires the representation of structural/semantic distinctions provided
for in the coding, markug formats, markup languages etc., that are
included in the baseline.

2. As we are already proposing to do, we should provide advice to
developers in the choice of an appropriate baseline. This includes the
principle that, other considerations being equal, semantically rich
formats should be preferred.

Received on Wednesday, 1 June 2005 00:33:32 UTC