IDE Minutes 2008 06 10
- Jon Ferraiolo, IBM
- Lori Hylan-Cho, Adobe
- Rich Thompson, IBM
- Phil Berkland, IBM
- Bertrand Le Roy, Microsoft
- Stew Nickolas, IBM, scribe
Jon: Starting from things in email from the most recent
Jon: The "description" element proposal is located here: http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Descriptive#Content_that_can_be_plain_text_or_HTML Jon: The proposal is to allow both plain text and HTML content
If the type is HTML then tools need to sanitize HTML Developers need to know that some tools will only support a common subset
Jon: As I looked at this is really boils down to the description always being treated as HTML (the content that is)
Jon: I propose a type attribute on the description element, whose default is plain text
Stew: Because the document is already been loaded as XML the developer must of already made sure the description sections were legal
XML, for example by using CDATA when content contains < character.
Phil: Does javadoc have this problem? (that all descriptions are treated as HTML)
Jon: Javadoc does not support rich markup?
Phil: I guess not
Jon: If there is no type processors treat the description as plain text, if you give type="text|html|pre"
Jon: Bertrand suggested via email we use mimetypes instead of text, html
Jon: I think 99% of descriptions will be plain text, developers will seldom use rich text stuff
Stew: I agree
Jon: Any objections to adding a type attribute?
Jon: Next question, what values (text|html|pre)
Jon: Bertrand, suggested mimetyoe
Jon: Mime types, text/plain, text/html,
Jon: Bertrand suggested for pre capability just include pre element in your markup
Lori: Sounds logical
Jon: Sounds fine
Phil: We need to make sure the spec lists explicit list of mime types
Jon: What to do with CDATA, sense is CDATA get stripped before going to browser. Valid XML (metadata, does not go to browser)
Jon: What is the processing model of CDATA? Proposal at bottom of page: http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Descriptive#Content_that_can_be_plain_text_or_HTML
The detailed processing model for the descriptive content is as follows:
- From the original source metadata file, extract the complete string of characters between the start element tag and the end element tag, including any white space and newlines. For example, with the <description> element, extract all characters between the <description> start tag and the </description> end tag. For <description>Here is the description </description>, the extracted text would be "Here is the description".
- Strip out all CDATA constructs. For example, with <description>PPP <[CDATA[-bbb-]]> QQQ</description>, the result text string would be "PPP -bbb- QQQ".
- Take appropriate measures such as whitelisting to filter out potentially malicious HTML constructs.
- Render the result of the previous steps using an engine capable of parsing and rendering rich text HTML content.
Jon: Any comments? None
Jon: Any disagree? None
Jon: OK, next is Icon
Jon: Wait until next week to discuss icon
Jon: Back to the email, there is a question about chaning the 'type' attribute to 'datatype' (as in should we)?
Jon: One point is that the attribute name 'type' may cause confusion
Lori: No confusion perceived
Jon: I believe is safer and more explicit
Rich: Yep, I prefer more explicit
Jon: Regarding the previous discussion (about description) do we call the attribute on description mimetype?
Bertrand: No existing html does not call mimeType
Jon: ok, for the description we'll call it type
Jon: BTW, type applies to property, parameter, return, etc. anything that has a datatype
Jon: Moving along lets discuss the single 'content' element question, specifically where should CSS be inserted int the document? For example, do we have a content element type of 'css'?
Lori: My proposal places it in the requires, if the require element has content it is inserted into the HEAD tag
Stew: Can we target other things for HEAD?
Jon: Jon we can add a meta target later if necessary, for example require type="LINK"
Jon: For this issue, we're OK
Lori: We added one more type Image
Jon: Accept? require='inline', yes
Jon: Moving on to discuss content type,
Jon: Stew proposed, view|edit|help, moved help to be its own tag last week
Jon: We did not resolve edit or help for the content element
Jon: BTW, Gadgets added multiple views, we'll need to look into that
Lori: Are content types mutually exclusve?
Rich: No, its really up to canvas or environment, for example, google shows property editor and view at the same time
Lori: What is Edit?
Rich: Your own specialized property editor
Lori: What is content?
Lori: I'm OK with multiple content nodes
Lori: Now do we have a requirement that there be only one of each type of content type (e.g. edit)?
Lori: OK, I likes this
Rich: This also allows types that the canvase does not know about that can be used by the widget
Jon: Back to google gadgets, they have recently added a view type to the specification, how do we handle the mapping?
Stew: I'll look into the possible mapping
Lori: We can use a custom type more that is used more like a custom tag
Jon: Processing rules for content
Jon: Locate the content with type='view' or the absence of a type attribute since the default is 'view'
Jon: For the property property editor, type='edit'
Jon: ok moving on, to See and See also
Bertrand: In general we need a way to cross-reference documentation with some mechanism for deep linking into other documents.
Bertand: Opinions from other IDE vendors?
Jon: Just seeAlso, revisit the see
Bertrand: Call to action from other IDE vendors on how to do it?
Jon: Will write-up and send email
Jon: Moving on to Version (from email)
Lets follow what we did in the hub
In this case, I was thinking that the processing model would be:
- Search left-to-right for the first ":".
- If a colon is found, then the text before the ":" is the StartVersionString and the text after the colon is the EndVersionString. For example, "1.0:2.0" would result in StartVersionString="1.0" and EndVersionString="2.0". For the case of "1.0beta2:2.0 build 298", the result would be StartVersionString="1.0beta2" and EndVersionString="2.0 build 298".
- If a colon is not found, set StartVersionString to the original value of the attribute and EndVersionString and EndVersionNumber to NotSpecified.
- See if the StartVersionString matches the pattern #[.#]*. If so, extract the leading numeric part at the front into StartVersionNumber. Else, set StartVersionNumber=0.
- See if the EndVersionString matches the pattern #[.#]*. If so, extract the leading numeric part at the front into EndVersionNumber. Else, set EndVersionNumber to NotSpecified
Jon: I'm not sure anyone will actually use the numeric values in practice, but at least it would be well-defined how to determine the numeric values.
Jon: Using '-' as seperateor, more likely text would have hypen and NOT ':', so, 1.0:2.0
Jon: Objections? none
Jon: OK, will change spec
Jon: We moved available and deprecated to being attribute, after the meeting I realized textual content may provide extra content.
Jon: Objection to revert to element?
Lori: Which one, available and deprecated
Stew: plain text? or like description?
Jon: Description it is, type="text/plain", type="text/html"