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.

DM,

Are you saying that the DTD has a rend attribute that can have several 
possible values at the same time?

While I don't doubt that is possible, I am not sure why anyone would 
want to do it.

Sounds like a hack to allow poorly written XSLT stylesheets.

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>.

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!

Patrick


DM Smith wrote:
[...][...]

Patrick Durusau wrote:[...]
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

[...]

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.
[...]

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.
[...]

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.
[...]
And I hope you are having a good and full night of sleep.

--DM[...][...]

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:
[...][...][...][...][...][...][...][...][...][...][...][...]
>>> 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.
>>>
>>>
>>>[...][...]
[...]

Patrick Durusau wrote:[...]
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'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.
[...][...]
>>>
>>> Are you saying that the DTD has a rend attribute that can have 
>>> several possible values at the same time?[...]
>>>
>>> While I don't doubt that is possible, I am not sure why anyone
would 
>>> want to do it.[...]
>>> Sounds like a hack to allow poorly written XSLT stylesheets.[...]
>>> 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>.[...]
>>> 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![...]
>>> 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.
>>>>
>>>>
>>>>
>>>[...]

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:[...][...]
>>>
>>> Are you saying that the DTD has a rend attribute that can have 
>>> several possible values at the same time?[...]
>>>
>>> While I don't doubt that is possible, I am not sure why anyone
would 
>>> want to do it.[...]
>>> Sounds like a hack to allow poorly written XSLT stylesheets.[...]
>>> 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>.[...]
>>> 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![...]
>>> 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.
>>>>
>>>>
>>>>
>>>[...]

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 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>[...][...]

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 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>[...][...]
[...]

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:[...][...]
>>>     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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>[...]