Loading ...
Sorry, an error occurred while loading the content.

Restifying Available to Promise

Expand Messages
  • bhaugen32
    Assuming this group is still alive (I know everybody s been busy evangelizing in W3C lists), I have a followup question on the purchase order scenarios. There
    Message 1 of 30 , Apr 4 10:42 AM
    View Source
    • 0 Attachment
      Assuming this group is still alive (I know everybody's been busy
      evangelizing in W3C lists), I have a followup question on the
      purchase order scenarios.

      There is a standard function in an ERP system called Available to
      Promise, or ATP for short.

      "Available" means "not already promised to somebody".

      It is used to decide if a purchase order can be fulfilled or not.
      It is usually used for purchase orders for products, so that is what
      I will describe here.

      There are a variety of APIs and algorithms, but they boil down to two
      main queries, which I will describe in plain English, not code:

      1. How much of a product is available to promise at a future time?
      For example, how many blue shoes can I get by tomorrow?
      The answer is a quantity.

      2. Is a specified quantity of a product at a specified time?
      For example, can I get 100 blue shoes tomorrow?
      The answer is a boolean.

      This query might be offered to a customer to use before they place an
      order, or it might be used by the order-taking Web resource before
      accepting an order.

      In REST terms, I assume this is a GET with parameters, and the Web
      resource to address is the Product (i.e. BlueShoe).

      How would you say it?

      Thanks,
      Bob Haugen
    • S. Mike Dierken
      Interesting. The URI (path+query) would point to the answer you want to give, having the path only point to the product is neato, but not required. To get
      Message 2 of 30 , Apr 4 2:40 PM
      View Source
      • 0 Attachment
        Interesting.

        The URI (path+query) would point to the answer you want to give, having the
        'path only' point to the product is neato, but not required.

        To get the availability:
        http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow

        To get the threshold (more than 100)
        http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow&ab
        ove=100

        But of course there are a million ways to slice it.
        You can narrow down the choices based on whether PUT/DELETE/POST are needed
        on the same resource - and they probably aren't. POST might be used to
        allocate out of the availability - but a business document probably will
        have that information & so you'd just submit it to the 'orders' collection &
        let the values be updated via business logic (meaning that the values from
        these two sample queries are 'synthetic' properties, derived from data
        manipulated via other actions)


        ----- Original Message -----
        From: "bhaugen32" <bhaugen32@...>
        To: <rest-discuss@yahoogroups.com>
        Sent: Thursday, April 04, 2002 10:42 AM
        Subject: [rest-discuss] Restifying Available to Promise


        > Assuming this group is still alive (I know everybody's been busy
        > evangelizing in W3C lists), I have a followup question on the
        > purchase order scenarios.
        >
        > There is a standard function in an ERP system called Available to
        > Promise, or ATP for short.
        >
        > "Available" means "not already promised to somebody".
        >
        > It is used to decide if a purchase order can be fulfilled or not.
        > It is usually used for purchase orders for products, so that is what
        > I will describe here.
        >
        > There are a variety of APIs and algorithms, but they boil down to two
        > main queries, which I will describe in plain English, not code:
        >
        > 1. How much of a product is available to promise at a future time?
        > For example, how many blue shoes can I get by tomorrow?
        > The answer is a quantity.
        >
        > 2. Is a specified quantity of a product at a specified time?
        > For example, can I get 100 blue shoes tomorrow?
        > The answer is a boolean.
        >
        > This query might be offered to a customer to use before they place an
        > order, or it might be used by the order-taking Web resource before
        > accepting an order.
        >
        > In REST terms, I assume this is a GET with parameters, and the Web
        > resource to address is the Product (i.e. BlueShoe).
        >
        > How would you say it?
        >
        > Thanks,
        > Bob Haugen
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
      • bhaugen32
        ... having the ... when=tomorrow ... when=tomorrow&ab ... I like it! Maybe just plain http://www.myinventory.foo/products/blueshoes/availability would present
        Message 3 of 30 , Apr 4 2:46 PM
        View Source
        • 0 Attachment
          "S. Mike Dierken" wrote:
          >
          > Interesting.
          >
          > The URI (path+query) would point to the answer you want to give,
          having the
          > 'path only' point to the product is neato, but not required.
          >
          > To get the availability:
          > http://www.myinventory.foo/products/blueshoes/availability/?
          when=tomorrow
          >
          > To get the threshold (more than 100)
          > http://www.myinventory.foo/products/blueshoes/availability/?
          when=tomorrow&ab
          > ove=100

          I like it!
          Maybe just plain
          http://www.myinventory.foo/products/blueshoes/availability
          would present something like an MRP inquiry, starting with the blue
          shoes on hand, followed by a list of scheduled receipts.

          (That's the way an ATP report often looks.)

          > But of course there are a million ways to slice it.
          > You can narrow down the choices based on whether PUT/DELETE/POST
          are needed
          > on the same resource - and they probably aren't. POST might be used
          to
          > allocate out of the availability - but a business document probably
          will
          > have that information & so you'd just submit it to the 'orders'
          collection &
          > let the values be updated via business logic (meaning that the
          values from
          > these two sample queries are 'synthetic' properties, derived from
          data
          > manipulated via other actions)

          I agree. Allocation requires a business commitment from a customer,
          usually in the form of an order.

          Thanks, Mike.

          -Bob Haugen
        • tlainevool
          I was wondering if there might be a way to slice this that may be a little more RESTful. In REST a resource represents a service or a data element, and
          Message 4 of 30 , Apr 25 12:04 AM
          View Source
          • 0 Attachment
            I was wondering if there might be a way to "slice" this that may be a
            little more RESTful. In REST a resource represents a service or a
            data element, and every significant resource should have a URI. In
            the given system there were two services: "availabiltiy amount"
            and "is quantity available", and one data element: the BlueShoe
            product. It seems that each of these should have their own URI so:

            Availability amount service:
            http://www.myinventory.com/services/availablequantity

            Is quantity availabilty service:
            http://www.myinventory.com/services/isavailable

            BlueShoe: http://www.myinventory.com/product/blueshoe

            Then to do the queries the following URIs would be used:

            1) http://www.myinventory.com/services/availablequantity?
            product=http://www.myinventory.com/product/blueshoe&when=tomorrow

            2) http://www.myinventory.com/services/isavailable?
            product=http://www.myinventory.com/product/blueshoe&when=tomorrow
            &above=100

            Like I said, this seems a little more RESTful to me, and I'm trying
            to figure out what the advantages of this approach would be other
            than that it just seems to be the right way. One thing is that it
            uses a standard way of naming the products (via URIs) instead of
            naming them by adding to a sub-path of an existing URI. This seems
            more extensible: to add new products into the system, you don't add
            new paths to the URI, just use new query strings. I

            Is this a real advantage? Are there any other advantages to doing it
            this way? Opinions would be appreciated.

            Thanks,

            Toivo Lainevool
            New Iron Systems

            --- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
            >
            > Interesting.
            >
            > The URI (path+query) would point to the answer you want to give,
            having the
            > 'path only' point to the product is neato, but not required.
            >
            > To get the availability:
            > http://www.myinventory.foo/products/blueshoes/availability/?
            when=tomorrow
            >
            > To get the threshold (more than 100)
            > http://www.myinventory.foo/products/blueshoes/availability/?
            when=tomorrow&ab
            > ove=100
            >
            > But of course there are a million ways to slice it.
            > You can narrow down the choices based on whether PUT/DELETE/POST
            are needed
            > on the same resource - and they probably aren't. POST might be used
            to
            > allocate out of the availability - but a business document probably
            will
            > have that information & so you'd just submit it to the 'orders'
            collection &
            > let the values be updated via business logic (meaning that the
            values from
            > these two sample queries are 'synthetic' properties, derived from
            data
            > manipulated via other actions)
            >
            >
            > ----- Original Message -----
            > From: "bhaugen32" <bhaugen32@y...>
            > To: <rest-discuss@y...>
            > Sent: Thursday, April 04, 2002 10:42 AM
            > Subject: [rest-discuss] Restifying Available to Promise
            >
            >
            > > Assuming this group is still alive (I know everybody's been busy
            > > evangelizing in W3C lists), I have a followup question on the
            > > purchase order scenarios.
            > >
            > > There is a standard function in an ERP system called Available to
            > > Promise, or ATP for short.
            > >
            > > "Available" means "not already promised to somebody".
            > >
            > > It is used to decide if a purchase order can be fulfilled or not.
            > > It is usually used for purchase orders for products, so that is
            what
            > > I will describe here.
            > >
            > > There are a variety of APIs and algorithms, but they boil down to
            two
            > > main queries, which I will describe in plain English, not code:
            > >
            > > 1. How much of a product is available to promise at a future
            time?
            > > For example, how many blue shoes can I get by tomorrow?
            > > The answer is a quantity.
            > >
            > > 2. Is a specified quantity of a product at a specified time?
            > > For example, can I get 100 blue shoes tomorrow?
            > > The answer is a boolean.
            > >
            > > This query might be offered to a customer to use before they
            place an
            > > order, or it might be used by the order-taking Web resource before
            > > accepting an order.
            > >
            > > In REST terms, I assume this is a GET with parameters, and the Web
            > > resource to address is the Product (i.e. BlueShoe).
            > >
            > > How would you say it?
            > >
            > > Thanks,
            > > Bob Haugen
            > >
            > >
            > >
            > > To unsubscribe from this group, send an email to:
            > > rest-discuss-unsubscribe@y...
            > >
            > >
            > >
            > > Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/
            > >
            > >
            > >
          • bhaugen32
            ... a ... Service seems to me a lot more like SOAP than REST. I think of resource as a significant business entity or an aggregation of business entities.
            Message 5 of 30 , Apr 25 4:34 AM
            View Source
            • 0 Attachment
              "tlainevool" wrote:
              > I was wondering if there might be a way to "slice" this that may be
              a
              > little more RESTful. In REST a resource represents a service or a
              > data element, and every significant resource should have a URI.

              "Service" seems to me a lot more like SOAP than REST.
              I think of resource as a significant business entity
              or an aggregation of business entities.
              Usually larger granularity than a data element.

              > In
              > the given system there were two services: "availabiltiy amount"
              > and "is quantity available", and one data element: the BlueShoe
              > product. It seems that each of these should have their own URI so:
              >
              > Availability amount service:
              > http://www.myinventory.com/services/availablequantity
              >
              > Is quantity availabilty service:
              > http://www.myinventory.com/services/isavailable

              Let's contrast that with Mike Dierken's original suggestion:
              http://www.myinventory.foo/products/blueshoes/availability/

              "Availability" is actually an aggregate business entity.
              It is the aggregate of on hand inventory plus the stream
              of expected receipts, minus the stream of expected demands.
              It might also be called MRP (Material Requirements Plan).

              "Availability" even has a standard representation:
              a time-phased table of planned inventory inputs and outputs with a
              running balance.

              A query into this table can show the available balance at some future
              date.

              As an old MRP jock, I like Mike's suggestion better.

              As to which is more RESTful, I leave that to further discussion.
              I'm a rookie here myself.

              -Bob Haugen
            • S. Mike Dierken
              ... My thoughts on REST are that one aspect implies lots of nouns, few verbs . When applied to HTTP, this means each URI would reasonably support
              Message 6 of 30 , Apr 25 11:51 AM
              View Source
              • 0 Attachment
                > >
                > > Is quantity availabilty service:
                > > http://www.myinventory.com/services/isavailable
                >
                > Let's contrast that with Mike Dierken's original suggestion:
                > http://www.myinventory.foo/products/blueshoes/availability/
                >

                >
                > As to which is more RESTful, I leave that to further discussion.
                > I'm a rookie here myself.

                My thoughts on REST are that one aspect implies 'lots of nouns, few verbs'.
                When applied to HTTP, this means each URI would reasonably support
                GET/PUT/POST/DELETE. If the system accepted changes to availability via
                HTTP, then a PUT to the URI might make sense - in this example,
                'availability' is a very synthesized entity and it probably doesn't make
                sense.

                The differences between the two are fairly minor.

                http://www.myinventory.com/services/availablequantity?product=http://www.myi
                nventory.com/product/blueshoe&when=tomorrow

                http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow

                I chose not to use full a URI to indicate the product, because I felt the
                owner of the resources would have their own 'internal ID' of the product,
                and I didn't expect them to be fully URI based for their keys - but they
                could just as easily be URIs.

                I also didn't break the problem down into functions and parameters - I tried
                to break it down into addressable information entities.
                This way it would be easy to 'hang new properties' off of a product via the
                path segments of a URI. But that is purely a stylistic opinion - I just like
                path based rather than query string based addressing. It helps me
                concentrate on information rather than function+parameters.

                Something I'm still thinking about is how a client acquires the URI to begin
                with. Either of these two approaches could return the same data, so they are
                equivalent from that point of view - but is one easier to use from the
                client? This gets into the "hyperlink .vs. generative" argument. I like the
                hyperlink approach because it has the promise of a client talking to these
                two different styles of URIs without knowing or caring - more loose
                coupling. But I like the generative approach because the client may have a
                fragment of information that is not part of the name/location of the
                hyperlink that has the URI, but is actually part of the value of the URI.

                Here are some concrete examples that help me think about the issues. In both
                cases the text 'productId' is a coordinating name. In both cases the client
                also knows the value 'blueshoes'. One difference is that the hyperlink
                examples has to list all possible values - which might be a bit much.

                --hyperlink1--
                <stuff>
                <availability
                productId='blueshoes'>http://www.myinventory.foo/products/blueshoes/availabi
                lity/?when=tomorrow</availability>
                </stuff>

                --hyperlink2--
                <product productId='blueshoes'>

                <availability>http://www.myinventory.foo/products/blueshoes/availability/?wh
                en=tomorrow</availability>

                <description>http://www.myinventory.foo/products/blueshoes/description/</des
                cription>
                </stuff>

                --generative1--
                <stuff>

                <availability>http://www.myinventory.foo/products/%productId%/availability/?
                when=tomorrow</availability>
                </stuff>

                --generative2--
                <stuff>
                <availability>http://www.myinventory.foo/products/<productId
                />/availability/?when=tomorrow</availability>
                </stuff>


                --generative3 (not recommened, since entities scare the bunnies and break
                lots of code)--
                <stuff>

                <availability>http://www.myinventory.foo/products/&productId;/availability/?
                when=tomorrow</availability>
                </stuff>
              • Toivo "Deutsch" Lainevool
                ... I m not sure if this is true. Roy Fielding dissertation defines a resource as Any information that can be named can be a resource: a document or image, a
                Message 7 of 30 , Apr 26 2:22 AM
                View Source
                • 0 Attachment
                  bhaugen32 wrote:
                  >
                  > "tlainevool" wrote:
                  > > I was wondering if there might be a way to "slice" this that may be
                  > a
                  > > little more RESTful. In REST a resource represents a service or a
                  > > data element, and every significant resource should have a URI.
                  >
                  > "Service" seems to me a lot more like SOAP than REST.
                  > I think of resource as a significant business entity
                  > or an aggregation of business entities.
                  > Usually larger granularity than a data element.
                  >

                  I'm not sure if this is true. Roy Fielding dissertation defines a
                  resource as "Any information that can be named can be a resource: a
                  document or image, a temporal service (e.g. "today's weather in Los
                  Angeles"), a collection of other resources, a non-virtual object (e.g. a
                  person), and so on." HTTP defines it as "A network data object or
                  service that can be identified by a URI". It seems like services are a
                  valid concept to assign a URI to.

                  Toivo Lainevool
                • Toivo "Deutsch" Lainevool
                  ... via ... make ... This is one concept I keep trying to get my head wrapped around. I ve been developing and using ORBs for a while, so I always leap to a
                  Message 8 of 30 , Apr 26 2:50 AM
                  View Source
                  • 0 Attachment
                    S. Mike Dierken wrote:
                    >
                    > My thoughts on REST are that one aspect implies 'lots of nouns, few
                    > verbs'.
                    > When applied to HTTP, this means each URI would reasonably support
                    > GET/PUT/POST/DELETE. If the system accepted changes to availability
                    via
                    > HTTP, then a PUT to the URI might make sense - in this example,
                    > 'availability' is a very synthesized entity and it probably doesn't
                    make
                    > sense.
                    >

                    This is one concept I keep trying to get my head wrapped around. I've
                    been developing and using ORBs for a while, so I always leap to a very
                    RPCish view. I see this as one of the main differences between RPC and
                    REST: RPC's whole reason for existing is to define NEW verbs, REST
                    limits them so that the underlying architecture can use the verbs
                    intelligently when doing things like security and caching. I have to
                    keep reminding myself that URIs do not identify methods or groups of
                    methods, they identify resources.

                    >
                    > Something I'm still thinking about is how a client acquires the URI to
                    > begin
                    > with. Either of these two approaches could return the same data, so
                    they
                    > are
                    > equivalent from that point of view - but is one easier to use from the
                    > client? This gets into the "hyperlink .vs. generative" argument. I
                    like
                    > the
                    > hyperlink approach because it has the promise of a client talking to
                    these
                    > two different styles of URIs without knowing or caring - more loose
                    > coupling. But I like the generative approach because the client may
                    have a
                    > fragment of information that is not part of the name/location of the
                    > hyperlink that has the URI, but is actually part of the value of the
                    URI.
                    >

                    This is an interesting topic. When it comes to the underlying
                    components in a RESTful system, the URI are opaque. The servers,
                    proxies and gateways don't care what the internal format of the URIs
                    are, but the system you build on top of it could care about the details.
                    Having the client be able to work with the format of the URI might make
                    for a more powerful system. If the system has a resource for returning
                    a product catalog, e.g.:

                    <products>
                    <product name="http://www.myinventory.foo/product/blueshoe">
                    <product name="http://www.myinventory.foo/product/redshoe">
                    ... etc ...
                    </products>

                    In that case it would be reasonable for the client to do a GET on the
                    name URI and receive a product information document. PUT/POST/DELETE
                    could also be used for modifying/deleting the product information.

                    The client could then also use these same product names in the query
                    part of the availability URIs, as I explained earlier, like this:
                    http://www.myinventory.com/services/availablequantity?product=http://www
                    .myi
                    nventory.com/product/blueshoe&when=tomorrow

                    In the earlier suggestion where the following URI was used:
                    http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro
                    w
                    The "blueshoe" product would be known by two names by the client, the
                    URI and the name "blueshoe".

                    I guess my point is that since we already have a way of naming things in
                    a REST system (i.e. URIs), why not use it for every name in the system?
                    This was one of the points made in Paul Prescod's xml.com article about
                    a RESTful version of UDDI; why use GUIDs when you already have URIs?

                    Toivo Lainevool
                  • bhaugen32
                    ... may be ... or a ... (e.g. a ... are a ... I am not a purist, and can go along with assigning a URI to a service. But when you already have a Product
                    Message 9 of 30 , Apr 26 5:21 AM
                    View Source
                    • 0 Attachment
                      "Toivo \"Deutsch\" Lainevool" wrote:
                      >
                      >
                      > bhaugen32 wrote:
                      > >
                      > > "tlainevool" wrote:
                      > > > I was wondering if there might be a way to "slice" this that
                      may be
                      > > a
                      > > > little more RESTful. In REST a resource represents a service
                      or a
                      > > > data element, and every significant resource should have a URI.
                      > >
                      > > "Service" seems to me a lot more like SOAP than REST.
                      > > I think of resource as a significant business entity
                      > > or an aggregation of business entities.
                      > > Usually larger granularity than a data element.
                      > >
                      >
                      > I'm not sure if this is true. Roy Fielding dissertation defines a
                      > resource as "Any information that can be named can be a resource: a
                      > document or image, a temporal service (e.g. "today's weather in Los
                      > Angeles"), a collection of other resources, a non-virtual object
                      (e.g. a
                      > person), and so on." HTTP defines it as "A network data object or
                      > service that can be identified by a URI". It seems like services
                      are a
                      > valid concept to assign a URI to.

                      I am not a purist, and can go along with assigning a URI to a service.

                      But when you already have a Product resource, it seems to me that
                      asking a Service for availability by Product is going backwards to
                      something more like a Web service. I like much better asking the
                      Product resource for its availability, especially when "availability"
                      itself is a well-recognized business aggregation with a standard
                      definition from APICS, the Production and Inventory Control Society.

                      In a Web business situation, I want my significant business entities
                      to be resources with URIs: products, orders, disbursements and
                      receipts, etc. I want them also to be hyperlinked to each other:
                      products to orders, orders to products, disbursements and receipts to
                      orders, etc.

                      All of the above is why REST makes more sense to me from a business
                      modeling perspective than SOAP.

                      As Mike Dierken says, I want more nouns than verbs.

                      As I said, this is just the way I think about it as a rookie.
                      But I've been working my way through some common business situations
                      and it's holding up pretty well so far.

                      -Bob Haugen
                    • S. Mike Dierken
                      ... From: Toivo Deutsch Lainevool ... You are right about the need for two names - I m just not sure what the best way of
                      Message 10 of 30 , Apr 26 5:10 PM
                      View Source
                      • 0 Attachment
                        ----- Original Message -----
                        From: "Toivo "Deutsch" Lainevool" <tlainevool@...>

                        >
                        > In that case it would be reasonable for the client to do a GET on the
                        > name URI and receive a product information document. PUT/POST/DELETE
                        > could also be used for modifying/deleting the product information.
                        >
                        > The client could then also use these same product names in the query
                        > part of the availability URIs, as I explained earlier, like this:
                        > http://www.myinventory.com/services/availablequantity?product=http://www
                        > .myi
                        > nventory.com/product/blueshoe&when=tomorrow
                        >
                        > In the earlier suggestion where the following URI was used:
                        > http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro
                        > w
                        > The "blueshoe" product would be known by two names by the client, the
                        > URI and the name "blueshoe".
                        >
                        You are right about the need for two names - I'm just not sure what the best
                        way of doing it is. It seems that using a URI for everything is a bit
                        excessive, but I haven't spent a lot of time in this area.
                      • bhaugen32
                        ... the ... PUT/POST/DELETE ... query ... product=http://www ... when=tomorro ... the ... the best ... bit ... I don t understand the two names argument. What
                        Message 11 of 30 , Apr 26 5:32 PM
                        View Source
                        • 0 Attachment
                          "S. Mike Dierken" wrote:
                          >
                          > ----- Original Message -----
                          > From: "Toivo "Deutsch" Lainevool" <tlainevool@n...>
                          >
                          > >
                          > > In that case it would be reasonable for the client to do a GET on
                          the
                          > > name URI and receive a product information document.
                          PUT/POST/DELETE
                          > > could also be used for modifying/deleting the product information.
                          > >
                          > > The client could then also use these same product names in the
                          query
                          > > part of the availability URIs, as I explained earlier, like this:
                          > > http://www.myinventory.com/services/availablequantity?
                          product=http://www
                          > > .myi
                          > > nventory.com/product/blueshoe&when=tomorrow
                          > >
                          > > In the earlier suggestion where the following URI was used:
                          > > http://www.myinventory.foo/products/blueshoes/availability/?
                          when=tomorro
                          > > w
                          > > The "blueshoe" product would be known by two names by the client,
                          the
                          > > URI and the name "blueshoe".
                          > >
                          > You are right about the need for two names - I'm just not sure what
                          the best
                          > way of doing it is. It seems that using a URI for everything is a
                          bit
                          > excessive, but I haven't spent a lot of time in this area.

                          I don't understand the two names argument.
                          What two names do you mean?
                          URI including "blueshoes" plus "blueshoes" all by itself?
                          Why is that a problem?

                          Nor do I understand "services/availability/?product="
                          vs "products/blueshoes/availability".

                          What am I missing?

                          >It seems that using a URI for everything is a bit
                          > excessive, but I haven't spent a lot of time in this area.

                          Why isn't it better for more things to have identities?
                          (I'm not sure where "excessive" begins, but for each product to have
                          its own URI does not seem to be even close to the edge.)
                        • Toivo "Deutsch" Lainevool
                          ... Yes. ... Anytime you have to keep track of one with two names I think you are asking for trouble. ... The difference is not major. To the underlying
                          Message 12 of 30 , Apr 26 6:10 PM
                          View Source
                          • 0 Attachment
                            >
                            > I don't understand the two names argument.
                            > What two names do you mean?
                            > URI including "blueshoes" plus "blueshoes" all by itself?

                            Yes.

                            > Why is that a problem?

                            Anytime you have to keep track of one with two names I think you are
                            asking for trouble.

                            >
                            > Nor do I understand "services/availability/?product="
                            > vs "products/blueshoes/availability".
                            >
                            > What am I missing?

                            The difference is not major. To the underlying components (HTTP
                            servers, caches, etc) they are identical. The difference comes if you
                            want to be able to generate these URIs and you want to use URIs for the
                            name of the product. Then the first one works.

                            >
                            > >It seems that using a URI for everything is a bit
                            > > excessive, but I haven't spent a lot of time in this area.
                            >
                            > Why isn't it better for more things to have identities?
                            > (I'm not sure where "excessive" begins, but for each product to have
                            > its own URI does not seem to be even close to the edge.)
                            >
                            I think he meant "using a URI" is excessive not "a URI for everything"
                            is excessive. I personally don't think it is excessive because
                            hopefully all this is automated so the user never sees these names.
                            URIs don't cost anything to create vs. a simple string. (Well maybe a
                            little extra memory, but not enough to really matter.)

                            Toivo Lainevool
                          • S. Mike Dierken
                            ... I agree that historically it has been easier to construct a uri via query terms - but that doesn t make path based URI construction difficult, it just
                            Message 13 of 30 , Apr 26 7:56 PM
                            View Source
                            • 0 Attachment
                              > >
                              > > Nor do I understand "services/availability/?product="
                              > > vs "products/blueshoes/availability".
                              > >
                              > > What am I missing?
                              >
                              > The difference is not major. To the underlying components (HTTP
                              > servers, caches, etc) they are identical. The difference comes if you
                              > want to be able to generate these URIs and you want to use URIs for the
                              > name of the product. Then the first one works.
                              I agree that historically it has been easier to construct a uri via query
                              terms - but that doesn't make path based URI construction difficult, it just
                              means nobody has provided a commonly recognized way to do it. It ends up
                              being an implementation preference, in my opinion, because I think you are
                              right when you point out that the underlying components see them as
                              identical.

                              I suppose that the choice between a short identifier and a URI (for product
                              ID in the examples) depends on how you acquire that product ID - in most
                              cases you will just echo back what the server gave to you initially (and a
                              full uri probably works better as a query term). A full-blown hypertext
                              approach would be URI through and through, but I believe that has problems
                              with interoperability - every service that wants to participate must know
                              the full URI of the product, which to me seems very constraining on
                              implementation choices. But it also means some sort of correlation ability
                              needs to exist - which might add too much complexity. I need to spend some
                              time and try different approaches out (which will be quite a while...)

                              >
                              > >
                              > > >It seems that using a URI for everything is a bit
                              > > > excessive, but I haven't spent a lot of time in this area.
                              > >
                              > > Why isn't it better for more things to have identities?
                              > > (I'm not sure where "excessive" begins, but for each product to have
                              > > its own URI does not seem to be even close to the edge.)
                              > >
                              > I think he meant "using a URI" is excessive not "a URI for everything"
                              > is excessive.
                              Yes.

                              > I personally don't think it is excessive because
                              > hopefully all this is automated so the user never sees these names.
                              > URIs don't cost anything to create vs. a simple string. (Well maybe a
                              > little extra memory, but not enough to really matter.)
                              I agree also - but without playing with a couple systems that do this - and
                              try to connect between them without them being aware of it - I'm not sure if
                              it is doable. It just seems that to bridge autonomous services (unaware of
                              each other) you are going to have to do uri mapping (not to mention message
                              format mapping...)
                            • Mark Baker
                              I m not sure I understand this two name problem. If I have a URI identifying me, and I want another URI that identifies the clothes I m currently wearing,
                              Message 14 of 30 , Apr 26 9:08 PM
                              View Source
                              • 0 Attachment
                                I'm not sure I understand this "two name" problem.

                                If I have a URI identifying me, and I want another URI that identifies
                                the clothes I'm currently wearing, the latter URI does not need to use
                                the former URI in a query term, or in any other fashion.

                                Just have;

                                http://www.markbaker.ca/

                                and

                                http://www.markbaker.ca/current-clothes/

                                Any relationship between the two should be expressed as an assertion
                                someplace. e.g.

                                <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>

                                MB
                                --
                                Mark Baker, Chief Science Officer, Planetfred, Inc.
                                Ottawa, Ontario, CANADA. mbaker@...
                                http://www.markbaker.ca http://www.planetfred.com
                              • Jeff Bone
                                ... Actually, there are some differences beyond the aesthetic; cf. the generative naming discussions here on list and on the Wiki about a month ago. Short
                                Message 15 of 30 , Apr 26 9:14 PM
                                View Source
                                • 0 Attachment
                                  On Fri, 2002-04-26 at 21:56, S. Mike Dierken wrote:
                                  >
                                  > It ends up
                                  > being an implementation preference, in my opinion, because I think you are
                                  > right when you point out that the underlying components see them as
                                  > identical.
                                  >

                                  Actually, there are some differences beyond the aesthetic; cf. the
                                  "generative naming" discussions here on list and on the Wiki about a
                                  month ago. Short version: there are things we can guarantee about
                                  path-based URI that can't be easily or at all guaranteed with path-based
                                  constructions.

                                  $0.02,

                                  jb
                                • Jeff Bone
                                  ... with query-based constructions. jb
                                  Message 16 of 30 , Apr 26 9:21 PM
                                  View Source
                                  • 0 Attachment
                                    On Fri, 2002-04-26 at 23:14, Jeff Bone wrote:
                                    >
                                    > that can't be easily or at all guaranteed with path-based
                                    > constructions.

                                    "with query-based constructions."

                                    jb
                                  • bhaugen32
                                    ... If you mean programmatically or in hyperlinks, if the URI is the identifier of the product, why would you ever need to use blueshoes all by itself?
                                    Message 17 of 30 , Apr 27 5:12 AM
                                    View Source
                                    • 0 Attachment
                                      "Toivo \"Deutsch\" Lainevool" wrote:
                                      > >
                                      > > I don't understand the two names argument.
                                      > > What two names do you mean?
                                      > > URI including "blueshoes" plus "blueshoes" all by itself?
                                      >
                                      > Yes.
                                      >
                                      > > Why is that a problem?
                                      >
                                      > Anytime you have to keep track of one with two names I think you are
                                      > asking for trouble.

                                      If you mean programmatically or in hyperlinks, if the URI is the
                                      identifier of the product, why would you ever need to use "blueshoes"
                                      all by itself? (Unless you were searching for its URI.)

                                      > > Nor do I understand "services/availability/?product="
                                      > > vs "products/blueshoes/availability".
                                      > >
                                      > > What am I missing?
                                      >
                                      > The difference is not major. To the underlying components (HTTP
                                      > servers, caches, etc) they are identical. The difference comes if
                                      you
                                      > want to be able to generate these URIs and you want to use URIs for
                                      the
                                      > name of the product. Then the first one works.

                                      Re "name of the product":
                                      The "products/blueshoes" URI *is* the Web resource identifier of the
                                      product. I don't understand how "services" is a better name for a
                                      product.

                                      Re availability syntax:
                                      Either way I have to get either a full URI or a partial URI from
                                      somewhere: sent in a message or found by query or navigation.

                                      In your "services/availability/?product=" notation, I needed to know
                                      not only that syntax plus the URI of the product.

                                      If I have the URI of the product, I can ask it for its business
                                      protocols which could be expressed in some as-yet-to-be-defined
                                      business protocol representation, related to Paul's WRDL.
                                      If I want to find "services/availability", I would need to do
                                      something similar.

                                      In other words, I don't see any big technical advantage to
                                      the "services/availability/?product=" notation.
                                      And semantically it seems like a Web service, not a resource.

                                      But I am pretty sure that the product will have its own URI,
                                      and "availability" is a natural property (thus sub-resource) of a
                                      product.

                                      So semantically I like it better. I think it will be a better way to
                                      compose relationships between resources.
                                    • Paul Prescod
                                      ... I want to stress this point. If you can connect things through hyperlinks rather than URI combinations then increasingly your service description can be
                                      Message 18 of 30 , Apr 27 1:57 PM
                                      View Source
                                      • 0 Attachment
                                        Mark Baker wrote:
                                        >
                                        > I'm not sure I understand this "two name" problem.
                                        >
                                        >...
                                        >
                                        > Any relationship between the two should be expressed as an assertion
                                        > someplace. e.g.
                                        >

                                        I want to stress this point. If you can connect things through
                                        hyperlinks rather than URI combinations then increasingly your "service
                                        description" can be considered an outgrowth of your "vocabulary
                                        description". I think of REST as pushing as much of the incompatibility
                                        of the world down into the vocabulary description. Vocabularies *must*
                                        vary (that's the whole point of XML). As we've demonstrated, method name
                                        do NOT NEED to vary, so push the incompatibility OUT of the method names
                                        and down into the markup.

                                        > <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>

                                        Mark uses RDF. I would typically use plain old xml.

                                        <person>
                                        <clothes href="/current-clothes"/>
                                        ...
                                        </person>

                                        Of course the virtue of RDF is that it is easily done out-of-line but
                                        IMO, out-of-line declarations are much harder to discover and maintain
                                        (were it otherwise, XML markup itself would be out-of-line). So I would
                                        say that out-of-line declarations are a fallback and inline I would
                                        discriminate against RDF because I wouldn't want to add syntactic
                                        complexity to my documents.

                                        Paul Prescod
                                      • S. Mike Dierken
                                        ... I think my examples were not that great and caused some confusion. The hyperlinking approaches seem to work, and my initial concern about whether all
                                        Message 19 of 30 , Apr 27 4:40 PM
                                        View Source
                                        • 0 Attachment
                                          > Mark Baker wrote:
                                          > >
                                          > > I'm not sure I understand this "two name" problem.
                                          > >
                                          > > Any relationship between the two should be expressed as an assertion
                                          > > someplace. e.g.
                                          > >

                                          I think my examples were not that great and caused some confusion.
                                          The hyperlinking approaches seem to work, and my initial concern about
                                          whether all parties would have the full URI or whether they would have only
                                          a 'short name' isn't all that worrisome. If the publisher of a product
                                          exposes the 'short name', then they could just as easily expose the full uri
                                          (but if we can't get them to expose the full uri, what are we to do?).

                                          The associations between resources still cause a well-known name to be
                                          used - but it is truly a name like 'availability' and not a value like
                                          'blueshoes'.

                                          -- http://www.myinventory.foo/products/blueshoes/ --
                                          <product>
                                          <availability>http://www.myinventory.foo/products/blueshoes/availability/?wh
                                          en=tomorrow</availability>
                                          <!-- OR -->
                                          <availability>http://www.myinventory.com/services/availablequantity?product=
                                          http://www.myinventory.com/product/blueshoe&when=tomorrow</availability>
                                          </product>

                                          The hyperlinking approach lets the URIs be completely unrelated - they can
                                          be 'path based' or 'service based' at the whim of the implementor. The
                                          'coordinating interface' becomes the names used to extract the values from
                                          the mass of xml (or rdf or whatever).

                                          A question:
                                          - what kind of server implementation is required if the portion that emits
                                          the 'product info' needs to know the full uri of the portion that deals with
                                          'availability' (it doesn't of course have to be an absolute uri, but
                                          whatever the uri looks like, all parts need to be aware of it)?
                                          Is there a way to avoid this apparent tight coupling on addressing? Am I
                                          missing something here?
                                        • Mark Baker
                                          ... I think in-line vs. out-of-line is a red herring. The RDF model can be serialized into many syntaxes to make in-line integration easier. What RDF provides
                                          Message 20 of 30 , Apr 27 6:19 PM
                                          View Source
                                          • 0 Attachment
                                            On Sat, Apr 27, 2002 at 01:57:24PM -0700, Paul Prescod wrote:
                                            > > <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>
                                            >
                                            > Mark uses RDF. I would typically use plain old xml.
                                            >
                                            > <person>
                                            > <clothes href="/current-clothes"/>
                                            > ...
                                            > </person>
                                            >
                                            > Of course the virtue of RDF is that it is easily done out-of-line but
                                            > IMO, out-of-line declarations are much harder to discover and maintain
                                            > (were it otherwise, XML markup itself would be out-of-line). So I would
                                            > say that out-of-line declarations are a fallback and inline I would
                                            > discriminate against RDF because I wouldn't want to add syntactic
                                            > complexity to my documents.

                                            I think in-line vs. out-of-line is a red herring. The RDF model can be
                                            serialized into many syntaxes to make in-line integration easier.

                                            What RDF provides is a generalized assertion model. That means that an
                                            RDF client can build up an understanding of a piece of representational
                                            state in an incremental manner, rather than the all-or-nothing approach
                                            of XML, where you either do or do not understand a schema.

                                            MB
                                            --
                                            Mark Baker, Chief Science Officer, Planetfred, Inc.
                                            Ottawa, Ontario, CANADA. mbaker@...
                                            http://www.markbaker.ca http://www.planetfred.com
                                          • Paul Prescod
                                            ... Yes, that s of course true. Here is why I think of it as in-line versus out-of-line: I am an XML person and I think that syntax matters. One of my
                                            Message 21 of 30 , Apr 28 1:03 AM
                                            View Source
                                            • 0 Attachment
                                              Mark Baker wrote:
                                              >
                                              >....
                                              >
                                              > I think in-line vs. out-of-line is a red herring. The RDF model can be
                                              > serialized into many syntaxes to make in-line integration easier.

                                              Yes, that's of course true. Here is why I think of it as in-line versus
                                              out-of-line: I am an XML person and I think that syntax matters. One of
                                              my complaints about SOAP is that it (and XLink, for that matter) is that
                                              it introduces a foreign syntax into XML vocabularies and thus makes them
                                              harder to teach and learn. That impacts their adoption characteristics.

                                              Out-of-line, I can stand RDF's syntax because that is really what it is
                                              optimized for: pointing into resources and making assertions about them.
                                              But inline, I can hardly imagine ever doing this:

                                              <rdf:RDF>
                                              <rdf:Description about="#">
                                              <s:Creator>Ora Lassila</s:Creator>
                                              </rdf:Description>
                                              </rdf:RDF>

                                              Rather than:

                                              <Creator>Ora Lassila</Creator>

                                              I think that this sort of disagreement was behind the RSS conflict and
                                              branch.

                                              Likely the right way to merge the worlds is to have a sort of RDF
                                              stylesheet which maps from XML into the RDF model. I would associate
                                              that with my document through a processing instruction. I believe the
                                              FourThought guys were working on such a technique.

                                              > What RDF provides is a generalized assertion model. That means that an
                                              > RDF client can build up an understanding of a piece of representational
                                              > state in an incremental manner, rather than the all-or-nothing approach
                                              > of XML, where you either do or do not understand a schema.

                                              That's certainly valuable but in my personal opinion, most XML users
                                              will not be willing to pay the price of designing their vocabularies
                                              specifically for RDF compatibility. For instance I much prefer the
                                              syntax of the real WSDL to the one outlined here:

                                              * http://www-106.ibm.com/developerworks/library/ws-rdf/

                                              For one thing, the idea of making one of the top-most elements "rdf:RDF"
                                              rather goes against the design of almost every XML schema language I've
                                              ever seen.

                                              Paul Prescod
                                            • bhaugen32
                                              ... have only ... product ... full uri ... do?). ... be ... like ... The most common way for companies that engage in B2B electronic commerce to communicate
                                              Message 22 of 30 , Apr 28 4:26 AM
                                              View Source
                                              • 0 Attachment
                                                "S. Mike Dierken" wrote:
                                                > my initial concern about
                                                > whether all parties would have the full URI or whether they would
                                                have only
                                                > a 'short name' isn't all that worrisome. If the publisher of a
                                                product
                                                > exposes the 'short name', then they could just as easily expose the
                                                full uri
                                                > (but if we can't get them to expose the full uri, what are we to
                                                do?).
                                                >
                                                > The associations between resources still cause a well-known name to
                                                be
                                                > used - but it is truly a name like 'availability' and not a value
                                                like
                                                > 'blueshoes'.

                                                The most common way for companies that engage in B2B electronic
                                                commerce to communicate product information is by publishing a
                                                catalog. It's common for customers to subscribe to the catalog and
                                                get periodic updates. The catalog will have URIs for each product.

                                                I expect something like 'Business Protocols" to become available soon.

                                                By "Business Protocols", I mean the scripts for getting catalogs,
                                                availability, ordering, claims, delivery and payment notifications,
                                                warranty service, etc.

                                                Many of those protocols will become available from libraries from
                                                standards groups and industry and trade associations. So "Business
                                                Protocols" might be a reference or a list of references to the common
                                                protocols a company can handle.

                                                So the first thing to do when you want to do business with a new
                                                trading partner is to get their business protocols.

                                                There is a catalog of common business processes here:
                                                http://www.ebxml.org/specs/bpPROC.pdf

                                                It contains categorized lists of business processes from EDI,
                                                RosettaNet, OAG, etc. Not much detail, just lists.

                                                Work is continuing on this catalog - adding more groups, including
                                                international trade processes. Executable international trade
                                                protocols will open the gates for many people who cannot engage in
                                                trade now because of the difficulties of the processes.

                                                Scripts for executable business processes are being developed in
                                                UN/CEFACT and ISO and several other organizations. For the most
                                                part, the scripts assume something like the EDI-mailbox Web service
                                                pattern. However, both UN/CEFACT and ISO are trying to be technology-
                                                independent, and so their process models should be able to be
                                                implemented in REST, at least via some twists.

                                                -Bob Haugen
                                              • S. Mike Dierken
                                                ... From: bhaugen32 ... Something that I ve run into is that (product) catalogs sometimes have pricing embedded within the catalog -
                                                Message 23 of 30 , Apr 28 11:13 AM
                                                View Source
                                                • 0 Attachment
                                                  ----- Original Message -----
                                                  From: "bhaugen32" <bhaugen32@...>

                                                  >
                                                  > The most common way for companies that engage in B2B electronic
                                                  > commerce to communicate product information is by publishing a
                                                  > catalog. It's common for customers to subscribe to the catalog and
                                                  > get periodic updates. The catalog will have URIs for each product.

                                                  Something that I've run into is that (product) catalogs sometimes have
                                                  pricing embedded within the catalog - which causes the catalog to be unique
                                                  to individual receivers - vendors don't have or want uniform pricing across
                                                  customers. If their process cannot 'normalize' out this information into
                                                  separate pricing documents then you get a huge amount of mostly redundant
                                                  information across the system as a whole. And when it gets this big - 60GB
                                                  per week for 10K customers lets say - then vendors feel they need batch
                                                  operations, scheduled updates, etc. leading away from a more
                                                  real-time/low-latency/event-driven message flow.

                                                  >
                                                  > I expect something like 'Business Protocols" to become available soon.
                                                  >
                                                  I agree with you. I think they will evolve from the coalescing of pockets of
                                                  use, rather than from standardization organizations though.
                                                • Uche Ogbuji
                                                  ... Quite dated, this is. I wrote it back in 2000, before I came to the same conclusion as you have: that it s more important to have mapping features from
                                                  Message 24 of 30 , Apr 29 12:13 AM
                                                  View Source
                                                  • 0 Attachment
                                                    On Sun, 2002-04-28 at 02:03, Paul Prescod wrote:
                                                    > Mark Baker wrote:
                                                    > >
                                                    > >....
                                                    > >
                                                    > > I think in-line vs. out-of-line is a red herring. The RDF model can be
                                                    > > serialized into many syntaxes to make in-line integration easier.
                                                    >
                                                    > Yes, that's of course true. Here is why I think of it as in-line versus
                                                    > out-of-line: I am an XML person and I think that syntax matters. One of
                                                    > my complaints about SOAP is that it (and XLink, for that matter) is that
                                                    > it introduces a foreign syntax into XML vocabularies and thus makes them
                                                    > harder to teach and learn. That impacts their adoption characteristics.
                                                    >
                                                    > Out-of-line, I can stand RDF's syntax because that is really what it is
                                                    > optimized for: pointing into resources and making assertions about them.
                                                    > But inline, I can hardly imagine ever doing this:
                                                    >
                                                    > <rdf:RDF>
                                                    > <rdf:Description about="#">
                                                    > <s:Creator>Ora Lassila</s:Creator>
                                                    > </rdf:Description>
                                                    > </rdf:RDF>
                                                    >
                                                    > Rather than:
                                                    >
                                                    > <Creator>Ora Lassila</Creator>
                                                    >
                                                    > I think that this sort of disagreement was behind the RSS conflict and
                                                    > branch.
                                                    >
                                                    > Likely the right way to merge the worlds is to have a sort of RDF
                                                    > stylesheet which maps from XML into the RDF model. I would associate
                                                    > that with my document through a processing instruction. I believe the
                                                    > FourThought guys were working on such a technique.
                                                    >
                                                    > > What RDF provides is a generalized assertion model. That means that an
                                                    > > RDF client can build up an understanding of a piece of representational
                                                    > > state in an incremental manner, rather than the all-or-nothing approach
                                                    > > of XML, where you either do or do not understand a schema.
                                                    >
                                                    > That's certainly valuable but in my personal opinion, most XML users
                                                    > will not be willing to pay the price of designing their vocabularies
                                                    > specifically for RDF compatibility. For instance I much prefer the
                                                    > syntax of the real WSDL to the one outlined here:
                                                    >
                                                    > * http://www-106.ibm.com/developerworks/library/ws-rdf/

                                                    Quite dated, this is. I wrote it back in 2000, before I came to the
                                                    same conclusion as you have: that it's more important to have mapping
                                                    features from XML to RDF than to squeeze everything into RDF syntax.


                                                    > For one thing, the idea of making one of the top-most elements "rdf:RDF"
                                                    > rather goes against the design of almost every XML schema language I've
                                                    > ever seen.

                                                    You might, then, want to check out the updated article:

                                                    http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/

                                                    Unfortunately, there is a bug in this article I've reported to the
                                                    editor. An XInclude I used did not get expanded. You'll know what I
                                                    mean if you read the article. If so, here's the link you want:

                                                    http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt

                                                    Might I also suggest my similar discussion WRT SOAP:

                                                    http://www-106.ibm.com/developerworks/webservices/library/ws-soaprdf/


                                                    --
                                                    Uche Ogbuji Fourthought, Inc.
                                                    uche.ogbuji@... http://fourthought.com
                                                    http://4Suite.org http://uche.ogbuji.net
                                                    Track chair, XML/Web Services One (San Jose, Boston):
                                                    http://www.xmlconference.com/
                                                    RDF Query using Versa -
                                                    http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
                                                    WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
                                                    XML, The Model Driven Architecture, and RDF @ XML Europe -
                                                    http://www.xmleurope.com/2002/kttrack.asp#themodel
                                                  • bhaugen32
                                                    ... have ... be unique ... pricing across ... into ... redundant ... An excellent point. Have you seen anybody do this normalization? How did it work out? ...
                                                    Message 25 of 30 , Apr 29 4:43 AM
                                                    View Source
                                                    • 0 Attachment
                                                      "S. Mike Dierken" wrote:
                                                      > Something that I've run into is that (product) catalogs sometimes
                                                      have
                                                      > pricing embedded within the catalog - which causes the catalog to
                                                      be unique
                                                      > to individual receivers - vendors don't have or want uniform
                                                      pricing across
                                                      > customers. If their process cannot 'normalize' out this information
                                                      into
                                                      > separate pricing documents then you get a huge amount of mostly
                                                      redundant
                                                      > information across the system as a whole.

                                                      An excellent point. Have you seen anybody do this normalization?
                                                      How did it work out?

                                                      > > I expect something like 'Business Protocols" to become available
                                                      soon.
                                                      > >
                                                      > I agree with you. I think they will evolve from the coalescing of
                                                      pockets of
                                                      > use, rather than from standardization organizations though.

                                                      I expect both of us are right. Here is some of my evidence for
                                                      organizations working on common business protocols:
                                                      * RosettaNet - electronics
                                                      * CIDX, chemical, adopted a lot of RNet
                                                      * PIDX, petroleum, adopting CIDX
                                                      * agXML, agriculture, adopting CIDX
                                                      * ebXML - took lots of ideas from RNet
                                                      * RNet now adopting at least some of ebXML
                                                      * AIAG, automotive, has previous X12 EDI standards, now adopting ebXML
                                                      * HIPAA, health care, US government mandate
                                                      * Travel (org?), adopting some of ebXML and also their own standards
                                                      * UCC, retail, somewhat like travel
                                                      * Telecom (org?), precursor to some of RNet

                                                      One point being that there is a lot of overlap and cross-referencing
                                                      between orgs. And whole bodies of commercial law and business
                                                      customs underly all of these protocols. Many of these people do
                                                      understand that "code rules" and so are attempting to codify legal
                                                      business practices.

                                                      And then some big companies like McDonalds and Walmart constitute
                                                      their own little universes...

                                                      Another point being that you could make up your own business
                                                      protocols, but be aware you are planting in a field where a big gang
                                                      plow is coming. It won't be as neat as the standards and industry
                                                      orgs and big companies like, but in many cases, you will be required
                                                      to follow some standardized protocol in order to do business.
                                                    • Mark Baker
                                                      ... I think syntax matters too. That s why I m not an XML person. 8-) ... Sure, but there s more information available in the former case. If the XML is
                                                      Message 26 of 30 , Apr 29 9:27 AM
                                                      View Source
                                                      • 0 Attachment
                                                        On Sun, Apr 28, 2002 at 01:03:30AM -0700, Paul Prescod wrote:
                                                        > Yes, that's of course true. Here is why I think of it as in-line versus
                                                        > out-of-line: I am an XML person and I think that syntax matters.

                                                        I think syntax matters too. That's why I'm not an XML person. 8-)

                                                        > One of
                                                        > my complaints about SOAP is that it (and XLink, for that matter) is that
                                                        > it introduces a foreign syntax into XML vocabularies and thus makes them
                                                        > harder to teach and learn. That impacts their adoption characteristics.
                                                        >
                                                        > Out-of-line, I can stand RDF's syntax because that is really what it is
                                                        > optimized for: pointing into resources and making assertions about them.
                                                        > But inline, I can hardly imagine ever doing this:
                                                        >
                                                        > <rdf:RDF>
                                                        > <rdf:Description about="#">
                                                        > <s:Creator>Ora Lassila</s:Creator>
                                                        > </rdf:Description>
                                                        > </rdf:RDF>
                                                        >
                                                        > Rather than:
                                                        >
                                                        > <Creator>Ora Lassila</Creator>

                                                        Sure, but there's more information available in the former case. If the
                                                        XML is going to be processed by a machine anyways, why is the latter
                                                        approach any better? I suppose if it were hand authored, but is that
                                                        what we're talking about here?

                                                        Also, I think the XML syntax for the RDF model is a horrible, nasty,
                                                        unnecessary thing. It should be killed.

                                                        > I think that this sort of disagreement was behind the RSS conflict and
                                                        > branch.
                                                        >
                                                        > Likely the right way to merge the worlds is to have a sort of RDF
                                                        > stylesheet which maps from XML into the RDF model. I would associate
                                                        > that with my document through a processing instruction. I believe the
                                                        > FourThought guys were working on such a technique.

                                                        I've heard talk of adorning schemas with the information necessary to
                                                        construct RDF. I like this in theory, though I fear for the practical
                                                        implications; primarily, additional network round-trips.

                                                        > > What RDF provides is a generalized assertion model. That means that an
                                                        > > RDF client can build up an understanding of a piece of representational
                                                        > > state in an incremental manner, rather than the all-or-nothing approach
                                                        > > of XML, where you either do or do not understand a schema.
                                                        >
                                                        > That's certainly valuable but in my personal opinion, most XML users
                                                        > will not be willing to pay the price of designing their vocabularies
                                                        > specifically for RDF compatibility.

                                                        For now, that's clearly true. As more RDF features are integrated into
                                                        tools, the cost of doing this will come down.

                                                        > For one thing, the idea of making one of the top-most elements "rdf:RDF"
                                                        > rather goes against the design of almost every XML schema language I've
                                                        > ever seen.

                                                        True, but I consider XML schema and other languages at that level, to be
                                                        transitional technologies. rdf:RDF (or something equivalent) will the
                                                        be the root element for a whole lot of content in a few years.

                                                        MB
                                                        --
                                                        Mark Baker, Chief Science Officer, Planetfred, Inc.
                                                        Ottawa, Ontario, CANADA. mbaker@...
                                                        http://www.markbaker.ca http://www.planetfred.com
                                                      • Paul Prescod
                                                        ... Yeah, it seems as if you re making some kind of joke. Look: it s only one line! ... Typo in that URI (localhost) but I figured it out. Still doesn t really
                                                        Message 27 of 30 , Apr 29 9:42 AM
                                                        View Source
                                                        • 0 Attachment
                                                          Uche Ogbuji wrote:
                                                          >
                                                          >...
                                                          > You might, then, want to check out the updated article:
                                                          >
                                                          > http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/
                                                          >
                                                          > Unfortunately, there is a bug in this article I've reported to the
                                                          > editor. An XInclude I used did not get expanded. You'll know what I
                                                          > mean if you read the article.

                                                          Yeah, it seems as if you're making some kind of joke. Look: it's only
                                                          one line!

                                                          If so, here's the link you want:

                                                          > http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt

                                                          Typo in that URI (localhost) but I figured it out. Still doesn't really
                                                          meet my requirements so I'll wait for more information on "document
                                                          definitions" or whatever else you are working on. For instance the root
                                                          namespace in this document is rdf:RDF which is not going to be
                                                          acceptable to XML people!

                                                          Maybe I'm unreasonable, but I'm looking for the total content of the RDF
                                                          stuff in my document to be:

                                                          <?rdf-metadata-mapping href=""?>

                                                          I would even be satisfied to put the RDF stuff in my XML or RELAX
                                                          schema.

                                                          Paul Prescod
                                                        • Paul Prescod
                                                          ... The only machines will see it argument is the typical of the approach of people who don t care about syntax. ;) ... Well yes, some of it is completely
                                                          Message 28 of 30 , May 1, 2002
                                                          View Source
                                                          • 0 Attachment
                                                            Mark Baker wrote:
                                                            >
                                                            > I think syntax matters too. That's why I'm not an XML person. 8-)

                                                            Mark Baker wrote:
                                                            >
                                                            > Sure, but there's more information available in the former case. If the
                                                            > XML is going to be processed by a machine anyways, why is the latter
                                                            > approach any better?

                                                            The "only machines will see it" argument is the typical of the approach
                                                            of people who don't care about syntax. ;)

                                                            > ... I suppose if it were hand authored, but is that
                                                            > what we're talking about here?

                                                            Well yes, some of it is completely hand-authored. But at some level it
                                                            is ALL hand-authored. After all, somebody has to write and debug the
                                                            programs that works with this stuff. Admittedly, RDF (no matter how
                                                            ugly) is not quite as bad as binary but nevertheless I see this: "don't
                                                            worry what it looks like" argument as a slippery slope to unreadability
                                                            and ultimately back to binary.

                                                            > Also, I think the XML syntax for the RDF model is a horrible, nasty,
                                                            > unnecessary thing. It should be killed.

                                                            You mean that RDF should not be XML-expressible at all? Use
                                                            s-expressions? Or do you mean you dislike all of the weird
                                                            minimizations?

                                                            >...
                                                            > I've heard talk of adorning schemas with the information necessary to
                                                            > construct RDF. I like this in theory, though I fear for the practical
                                                            > implications; primarily, additional network round-trips.

                                                            The relationship between documents and schemas will typically be many to
                                                            one so you can do a lot of caching of schemas. Sophisticated RDF use is
                                                            already dependent on schemas (RDF schemas) to get subclassing and
                                                            inferencing information, isn't it? So if you want high volume use of RDF
                                                            I think you'll have to figure out schema caching technologies. Is it
                                                            really feasible to use RDF without one of: a) a schema or b) a priori
                                                            knowledge of the vocabulary?

                                                            >...
                                                            > > That's certainly valuable but in my personal opinion, most XML users
                                                            > > will not be willing to pay the price of designing their vocabularies
                                                            > > specifically for RDF compatibility.
                                                            >
                                                            > For now, that's clearly true. As more RDF features are integrated into
                                                            > tools, the cost of doing this will come down.

                                                            I don't see it as a tools cost but as a readability cost. Sprinkling all
                                                            of that RDF junk through my document is, imo, as unacceptable as
                                                            sprinkling SOAP voodoo into my messages. I guess it boils down to: I
                                                            think you optimize the XML for readability and processability *as XML*
                                                            and then figure out how to get the benefits of protocols and metadata
                                                            engines etc. You think that RDF is primary and that XML is just a
                                                            container for it.

                                                            But if that's true then RDF should use an optimized-for-RDF syntax, not
                                                            XML at all.

                                                            Paul Prescod
                                                          • Mark Baker
                                                            I ll try to keep this REST-focused. ... I dislike that the triple structure of the RDF model is being shoehorned into a tree based syntax. It s unnatural, and
                                                            Message 29 of 30 , May 2, 2002
                                                            View Source
                                                            • 0 Attachment
                                                              I'll try to keep this REST-focused.

                                                              On Wed, May 01, 2002 at 10:20:27AM -0700, Paul Prescod wrote:
                                                              > > Also, I think the XML syntax for the RDF model is a horrible, nasty,
                                                              > > unnecessary thing. It should be killed.
                                                              >
                                                              > You mean that RDF should not be XML-expressible at all? Use
                                                              > s-expressions? Or do you mean you dislike all of the weird
                                                              > minimizations?

                                                              I dislike that the triple structure of the RDF model is being
                                                              shoehorned into a tree based syntax. It's unnatural, and it
                                                              shows.

                                                              > > I've heard talk of adorning schemas with the information necessary to
                                                              > > construct RDF. I like this in theory, though I fear for the practical
                                                              > > implications; primarily, additional network round-trips.
                                                              >
                                                              > The relationship between documents and schemas will typically be many to
                                                              > one so you can do a lot of caching of schemas. Sophisticated RDF use is
                                                              > already dependent on schemas (RDF schemas) to get subclassing and
                                                              > inferencing information, isn't it?

                                                              Yes, but RDF Schema is so general that it will likely be a built-in
                                                              for all processors. The same can't be said of vCard-in-XML, or
                                                              Docbook, etc..

                                                              That's the issue, I believe. Schemas can indeed be cached, but that
                                                              you'd need to get them in the first place is what hurts.

                                                              > > For now, that's clearly true. As more RDF features are integrated into
                                                              > > tools, the cost of doing this will come down.
                                                              >
                                                              > I don't see it as a tools cost but as a readability cost. Sprinkling all
                                                              > of that RDF junk through my document is, imo, as unacceptable as
                                                              > sprinkling SOAP voodoo into my messages. I guess it boils down to: I
                                                              > think you optimize the XML for readability and processability *as XML*
                                                              > and then figure out how to get the benefits of protocols and metadata
                                                              > engines etc. You think that RDF is primary and that XML is just a
                                                              > container for it.
                                                              >
                                                              > But if that's true then RDF should use an optimized-for-RDF syntax, not
                                                              > XML at all.

                                                              Mostly, yes. Sometimes you need the additional value that XML adds;
                                                              Unicode, xml:lang, xml:space, xml:base, etc..

                                                              From a purely REST POV, I want to use content negotiation to retrieve
                                                              RDF (N3, but XML if that's required) representations of resources.

                                                              MB
                                                              --
                                                              Mark Baker, Chief Science Officer, Planetfred, Inc.
                                                              Ottawa, Ontario, CANADA. mbaker@...
                                                              http://www.markbaker.ca http://www.planetfred.com
                                                            • Paul Prescod
                                                              ... Aren t you comparing apples and oranges? RDF Schema is a schema language, like RELAX NG or XML Schema. AFAIK, individual RDF vocabularies have individual
                                                              Message 30 of 30 , May 3, 2002
                                                              View Source
                                                              • 0 Attachment
                                                                Mark Baker wrote:
                                                                >
                                                                >...
                                                                >
                                                                > Yes, but RDF Schema is so general that it will likely be a built-in
                                                                > for all processors. The same can't be said of vCard-in-XML, or
                                                                > Docbook, etc..
                                                                >
                                                                > That's the issue, I believe. Schemas can indeed be cached, but that
                                                                > you'd need to get them in the first place is what hurts.

                                                                Aren't you comparing apples and oranges? RDF Schema is a schema
                                                                language, like RELAX NG or XML Schema. AFAIK, individual RDF
                                                                vocabularies have individual schemas expressing their type relationships
                                                                and inferencing rules, just as individual XML vocabularies have
                                                                individual schemas.

                                                                As I've heard you describe your idealized RDF bootstrapping process it
                                                                involves recognizing that you don't understand an assertion and then
                                                                looking up the definition and if you don't understand that you look up
                                                                the definition of that and if you don't, etc. etc. So whereas the XML
                                                                schema process is typically "flat" (barring a lot of inheritance or a
                                                                very modularized schema), the evaluation of an RDF expression could
                                                                require very deep recursion.

                                                                >...
                                                                >From a purely REST POV, I want to use content negotiation to retrieve
                                                                > RDF (N3, but XML if that's required) representations of resources.

                                                                Maybe in the long term. In the medium term I think it is more practical
                                                                to do the "generic XML"->RDF transformation on the client side so I am
                                                                on the lookout for technologies that will allow that.

                                                                Paul Prescod
                                                              Your message has been successfully submitted and would be delivered to recipients shortly.