[osis-core] Re: [osis-user] class vs type
Patrick Durusau
patrick at durusau.net
Sat Mar 11 13:30:17 MST 2006
Troy,
Troy A. Griffitts wrote:
> 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.
>
Err, we will have to wait for DM to respond but I thought his point was
that it is better to *not* store private date in an osis doc.
In other words, he wants a want to transform private data into a public
format, that is to keep the information but in an OSIS form.
Is that close DM?
This may not be a type question although it started off talking abou the
type attriubte.
It seems that what DM needs to record is display behavior. I am not sure
I want to attempt to define even a fairly extensive range of display
behavior but that is without really looking to see what that would take.
It might be a fairly good sized list but any one application would only
need a few of those.
Sorta like type on milestone. There are any number of uses for
milestones but with very few values we caught the vast number of usual
cases where it would be used.
Since I haven't looked I have no feel for whether such a list could be
created for display-behaviors, but suspect there must be some set of
usual and customary display behaviors, due to the limitations of
browsers if nothing else. All sorts of things are "possible" but
increasingly unlikely towards the margins.
Hope you are having a great day!
Patrick
> -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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> osis-core mailing list
> osis-core at bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
>
>
>
--
Patrick Durusau
Patrick at Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005
Topic Maps: Human, not artificial, intelligence at work!
More information about the osis-core
mailing list