OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[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