-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consensus on the function of <activity> element ? #81
Comments
Seems to me that the "type" attribute serves a purpose in that it provides a way to designate activities as empty elements. Or is there good a way to include "activity" as an empty element while doing away with "type" attribute? |
@bnhiebert Ben, I am still not sure how we are working with "purpose" at the "entry" level and "activity" at the "block" level. How are you using these elements? Could you suggest a couple of your entries as examples where "purpose" and "activity" are both used within an "entry"? |
Actually I have been marking "activity" at the block level to comport with the schema, but I think you raise a good question: why are we, in fact, labeling "activity" at the block level but not "purpose"? I wonder if we might move activity up to the entry level since it's our main unit? |
@bnhiebert Ben, that makes sense to me, especially if activity is a refinement of purpose. Wondering if others have any thoughts around this issue. |
I'll redefine the DTD for purpose and activity. Each will be:
|
Changed in DTD, some examples: Empty, at beginning of
Empty, at beginning of
Empty and wrapping text at beginning of
|
I know we haven't resolved this question.
I am not sure why "type" attribute has to be mandatory for "activity". Also, how have we decided to use "activity" within "block"?
testentry.dtd has the following definition for "activity", can we make "type" as not mandatory?
!ELEMENT activity (#PCDATA|activity|material)*
!ATTLIST activity
type NMTOKEN #REQUIRED
The text was updated successfully, but these errors were encountered: