From MemberWiki

Attendees

• Jon Ferraiolo, IBM
• Lori Hylan-Cho, Adobe
• Rich Thompson, IBM
• Phil Berkland, IBM
• Bertrand Le Roy, Microsoft
• Stew Nickolas, IBM, scribe

Minutes

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)

All: Agree

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:

1. 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".
2. Strip out all CDATA constructs. For example, with <description>PPP <[CDATA[-bbb-]]> QQQ</description>, the result text string would be "PPP -bbb- QQQ".
3. Take appropriate measures such as whitelisting to filter out potentially malicious HTML constructs.
4. 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

Jon: Yep

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?

Rich: HTML

Jon: HTML

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)?

Stew: No

Lori: OK, I likes this

Rich: This also allows types that the canvase does not know about that can be used by the widget

Lori: Great

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: For help type='help'Lori: Question, property inspectors require a javascript API to work, can we include javascript included, yes

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.

Jon: Use javascript to make link happpen?

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:

1. Search left-to-right for the first ":".
2. 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".
3. If a colon is not found, set StartVersionString to the original value of the attribute and EndVersionString and EndVersionNumber to NotSpecified.
4. See if the StartVersionString matches the pattern #[.#]*. If so, extract the leading numeric part at the front into StartVersionNumber. Else, set StartVersionNumber=0.
5. 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"