[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] FW: Tuesday 1-2pm ok with everyone?
Per the discussion today around the Customized use case, here's some internal correspondence around it. Eilon -----Original Message----- From: Timothy N. Jones [mailto:tim@crossweave.com] Sent: Wednesday, March 27, 2002 1:39 AM To: Ravi Konuru Cc: eilon.reshef@webcollage.com; kevin.brinkley@intel.com Subject: Re: Tuesday 1-2pm ok with everyone? > Today's notes. Pls add anything else that I missed or mis-stated. > Eilon, Ravi, Tim. > ----------------------- > Discussion: > How different are property and stream oriented adaptations in > terms of the information they need to specify? > Ravi: They overlap a lot, main extra attribute is the locator > in the case of stream oriented adaptation. > Eilon: Lets have one solution instead of providing two. > Tim: Permissions is something that they both overlap on. Just to clarify my thoughts on the relationship between stream-oriented/consumer-side adaptation and property-oriented/provider-side adaptation: I feel that the requirements for the former are a superset of those for the latter. Specifically, I envision an additional layer of software between the provider and consumer that can wrap, for example, a legacy HTML web app and provide a property-oriented adaptation interface for it (thus avoiding the need to modify the original app). This layer, which could be supplied by a third party, would work by reading a metafile containing bindings of properties to locators in the app's original pages. Once the properties are bound to items within the pages via the locators, they can be associated with permissions and value constraints as in the standard property-oriented cases. > Requirements: > Locators should be more than just XPath > - Stylesheets, html, URLs, XHTMLs, text (words in the html document). As I was thinking about the things that locators needed to locate, I came up with the following list: - URLs to be rewritten - adaptable markup (i.e., document structure) - adaptable text (i.e., document content) - adaptable styling I think that XPath could meet the first three requirements for locators, with the addition of a way to index a substring within a particular text node (perhaps some sort of regexp grouping mechanism). I'm not certain whether XPath expressions are transformable into CSS locators, so the styling requirement is a little less clear. The problem with XPath-based locators is that they require the source pages to be XHTML. I believe that many legacy apps which are candidates for the stream-oriented adaptation may not necessarily be in XHTML format, however, and the conversion from HTML to XHTML is not well defined in practice (there is a lot of very bad HTML "in the wild" that requires certain heuristics to convert into XHTML). Thus, if we use XPath for locators, I think they need to be accompanied by the HTML->XHTML transform whose output they apply to. The only alternative to XPath for locators I have thought of is some sort of DOM expression language that would allow for similar filtering of HTML nodes. I don't find this prospect especially appealing. In any case, the particular language used for the locators is probably not relevant to the requirements. > Permissions: > e.g Consumer is allowed to remove a logo. > e.g Consumer is allowed insert constraints. Some questions I have regarding the permissions model include: - Implicit vs. explicit allow/deny; do you identify things that can or cannot change, or some combination? - Are constraints an attribute of permissions for specific properties? How could you specify that logo A may be removed, but only if the text B is changed to either C or D? Some of the XForms validation technology may be useful here. - Is there a permissions hierarchy (probably depends on a property hierarchy); if a table is marked adaptable, does that mean the cells are unlocked too? > Stream oriented adaptation benefit: > Standardizing the property description language with two additional > attributes per element > - Locator > - Transformer, left-to-right, right-to-left? > first is a good move. would allow third party tools to use the > document as input and generate a pure property based service. It > becomes a stepping stone to build a property based service. > PROPOSAL: > - Based on the discussion today and noticing the commonality > between the two approaches, I suggest that we choose > the section names to be stream-oriented adaptation and operation > oriented adaptations since both make use of properties. > - We use the name property description language in both > sections. > Todo: > - Reorg the word document. > - work individually on the use cases and work through email. (ravi, > tim:stream-oriented, Eilon, Kevin: operation oriented). > Ravi Konuru > eBusiness Tools and Frameworks, IBM Research > office: 914-784-7180, tieline 8-863-7180; fax -3804 Regards, Tim
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC