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

[Troy A. Griffitts]

Patrick and DM,
	Very good point that it forces discussion about unresolved problems. 
But I'm not convinced we're not suggesting addition of the same thing: 
multiple x- attribute values on the type attribute to solve the problem.

	It seems the same to me:
<tag type="x-multivalue:a:b:c">
and
<tag private="rend:a rend:b rend:c">

I think I'd prefer the syntax of the later, because it preserves 'type' 
to allow something OSIS-valid for tag.

The more fundamental question arises... do we have any tags where it 
would be logical to allow multiple OSIS-valid types?  or "Can a tag be 
of multiple types simultaneously?"  And if so, what does subType mean in 
that context?

I still agree that DM's point is good.  Currently, it's hard to store 
private data in an osis doc, and that might be a good thing.

	-Troy.



Patrick Durusau wrote:
> DM,
> 
> I don't thinks that Tro was implying that he wasn't taking the problem 
> seriously.
> 
> I do think you have a good point about avoiding, to the extent 
> possible,  proprietary extensions that would decrease portability.
> 
> Ultimately that is to no small degree a question of judging the tradeoffs.
> 
> Troy: What do you think about DM's comment in terms of embedding 
> arbitrary data that may not be documented or standardized?
> 
> Hope you are having a great day!
> 
> Patrick
> 
> DM Smith wrote:
> 
>> I think private would be good as a convienent place for a work-ahead, 
>> but I'd be concerned that it be used for a work around without 
>> meaningful discussion here. And I'd be concerned if it became an easy 
>> way out. As it stands, the problems I face and have posted here are 
>> real and have been taken seriously. I think in part because there is 
>> no (good) way to do it in OSIS. I've really appreciated the progress 
>> each version of OSIS has made. I'd like to see that continue.
>>
>> I have worked with a few DTD's now and I am impressed with OSIS. Most 
>> of the other DTDs allow for arbitrary markup that in essence makes a 
>> document proprietary as processing it would require custom routines. 
>> The way OSIS is written right now, only the attributeExtensions are 
>> proprietary.
>>
>> Troy A. Griffitts wrote:
>>
>>> Patrick,
>>>     A while back, we had briefly discussed adding a global 'private' 
>>> attribute to the schema.  Basically, a place for organizations to 
>>> place private use information on any tag.  Not sure where people fell 
>>> on the sides of that issue, but I would be in favor of such an 
>>> attribute.
>>>
>>> o    It would allow me to have a basic valid OSIS document while we 
>>> debate how to move all the private data into best practice OSIS.
>>> o    It would allow helpful runtime information to be stored by our 
>>> engine and still allow schema validation against the document.
>>> o    It would allow any data to be stored (like DM's example) which 
>>> don't directly map to OSIS.
>>>
>>>
>>>
>>> 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?
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>