[osis-core] [osis-user] class vs type

[DM Smith]

Patrick Durusau wrote:
> DM,
>
> I take it is your requirement that you be able to have NMTOKENS as the 
> data type for the type attribute?
The requirement is to have a space separated list of valid "types". It 
does not matter to me if type is the correct attribute. You pick. If you 
think that type is the right attribute to satisfy this requirement, then 
I also suggest that it be added to subType as well. Though, I don't see 
much point in subType, if I can have a "list" of values for type.

Also, NMTOKEN probably won't work as it is not backward compatible with 
the definition of "attributeExtension", which allows characters that are 
not allowed in NMTOKEN.

Thank you very much. In the meantime, I'll use a form that can be 
reprocessed in a lossless fashion into that.

>
> I don't have any strong objections to space delimited data types so I 
> will pass it along to the core group and see if we can get a consensus 
> on that.
>
> Our next release will be OSIS 2.5 next Fall. I am hopeful we will see 
> some more tools and stylesheets posted in the meantime.

I'll see what I can provide.
Today, we have a stylesheet, but it handles a subset of OSIS and is 
specific to BibleDesktop.
And a validator of OSIS written in Java. Both are LGPL.

>
> Hope you are having a great day!
>
> Patrick
>
>
>
>
> DM Smith wrote:
>
>>
>>
>> Patrick Durusau wrote:
>>
>>> DM,
>>>
>>> Are you saying that the DTD has a rend attribute that can have 
>>> several possible values at the same time?
>>
>> Yes. Rend is defined as NMTOKENS. Which allows a space separated list 
>> of NMTOKEN.
>> The global attributes on elements in this system are:
>>    id      ID          #IMPLIED
>>    lang    IDREF       #IMPLIED
>>    n       CDATA       #IMPLIED
>>    rend    NMTOKENS    #REQUIRED
>>    type    NMTOKEN     #IMPLIED
>>
>> In some cases rend is not required.
>>
>> I have mapped
>>    this DTD's    OSIS's
>>    id            id
>>    lang          xml:lang
>>    n             n
>>    rend          subType
>>    type          type
>>
>>
>>>
>>> While I don't doubt that is possible, I am not sure why anyone would 
>>> want to do it.
>>
>>
>> It does not quite matter why. I am working with a legacy document 
>> that has it and I need to preserve it.
>> It is needed to express that an element belongs to different classes 
>> of presentation simultaneously. See below for more.
>>
>>>
>>> Sounds like a hack to allow poorly written XSLT stylesheets.
>>
>>
>> It has nothing to do with XSLT stylesheets. Its for CSS stylesheets. 
>> XSL was originally intended to allow the transformation and the 
>> styling of a document. XSLT only implemented the transformation 
>> aspect. IIRC, it was felt that CSS would do the job of presentation. 
>> I haven't looked at it yet but it looks like xsl-fo is intended to 
>> style a document.
>>
>> The value of the HTML class attribute and this DTD's rend attribute 
>> is that it allows for the separation of presentation and content. 
>> Prior to it, one embedded the presentation directly into the document.
>>
>>>
>>> For example, if I have <q type = "emphasis">, even though I only 
>>> have one value for type, nothing prevents me from having different 
>>> renderings of the contents of <hi> based upon its position in the 
>>> markup tree, for example <hi type="emphasis"> being rendered 
>>> differently when it is a child of <title> from when it is a child of 
>>> <p> versus when it is a child of <q>.
>>
>>
>> This is absolutely true and has no bearing on whether rend has one 
>> value or multiple ones. Or whether having multiple value is of any 
>> value (pun intended).
>>
>> Allowing multiple values allows the expression of different kinds of 
>> roles/dimensions to be used at the same time.
>>
>> For example, we may want an ordered list or an unordered list. And 
>> because nesting is allowed, we may have lists of lists. And any list 
>> in the tree can be either. But what if we want to have different 
>> kinds of ordered lists and unordered lists.
>> Say
>>    revealed - all the children of a node are shown with the parent
>>    initially-hidden- all the children of a node are initially hidden 
>> but stay shown until hidden again
>>    popup - shown for a time when a user expresses interest in them.
>> And, as an processing optimization it is needed to be known whether 
>> the list of children is to not wrap, wrap in a narrow presentation or 
>> a wide presentation.
>>
>> And in this example, it is both possible and reasonable to have a 
>> list of children that have different behaviors.
>> (This is a simplification of real world example of a system I wrote 
>> using CSS. There were other dimensions as well, such as data source: 
>> synthetic, program generated, user input. The HTML document were 
>> simple lists with <ul> and <ol> having multiple class values, with 
>> each class value representing a different concept.)
>>
>> To do this with a single value, I would need one for each possible 
>> combination; in this case a set of 2x3x3=18 different values. (Well 
>> actually 9, because HTML has ul and ol)
>>
>> In the case at hand, the element is a paragraph tag. It is not clear 
>> what the different values are, but let me suppose that they deal with 
>> justification, first-line indentation, subsequent-line indentation, 
>> line spacing, handling of first letter, etc. The application of these 
>> behaviors is entirely unpredictable in the document, so creating a 
>> general purpose stylesheet is out of the question and a specific one 
>> would end up as a complex program that has too great a knowledge of 
>> the document.
>>
>> Since I am dealing with transforming a legacy document into OSIS, I 
>> need a way to preserve the values. I am wondering how. (As a 
>> programmer, I can figure out many work arounds, such as littering the 
>> document with hi elements or replacing spaces with a character that 
>> is not allowed in NMTOKEN, like ':' type="x-multivalue:a:b:c") And if 
>> this ability will be added to a later version of osis, I would like 
>> to pick a hack that would allow a good path to it tomorrow.
>>
>> In order to separate presentation from structured content, there 
>> needs to be a semantic for deterministically attaching presentation 
>> to content. This is what the class and rend attribute provide.
>>
>>>
>>> Does that catch the gist of the problem or have I misunderstood the 
>>> issue? (It is 5 AM local time so the latter is entirely possible.)
>>>
>>> Hope you are having a great day!
>>
>> And I hope you are having a good and full night of sleep.
>>
>> --DM
>>
>>>
>>> Patrick
>>>
>>>
>>> DM Smith wrote:
>>>
>>>> In html elements define a class attribute which indicates that a 
>>>> particular element in its context belongs to a class of that 
>>>> element. The primary use of this is to indicate where styles can be 
>>>> attached. It appears that type can be used for the same purpose, 
>>>> but not quite. In html, class is defined as "class    space 
>>>> separated list of classes" It's type is CDATA, but in spirit is 
>>>> NMTOKEN. What this allows is for an element to be cross-classified. 
>>>> That is more than one class can apply.
>>>>
>>>> However in OSIS there is only one type "word" that can be used.
>>>>
>>>> I am working to convert an xml document to OSIS. This document's 
>>>> DTD defines an attribute, rend, in much the same way as class, in 
>>>> that it is a "role" to which style should be applied, with the 
>>>> possibility of several "roles".
>>>>
>>>> What is the proper way to do this?
>>>>
>>>> I can figure out several ways to do this but none seem quite right. 
>>>> For example, artificially, I can nest <hi> elements to achieve a 
>>>> similar, but not quite the same result.
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>