Re: rdf accommodation

Paul Tyson <phtyson@sbcglobal.net> writes:

> Norman Walsh wrote:
>> Paul Tyson <phtyson@sbcglobal.net> writes:
>>
>>
>>>
>>>1. Eliminate the requirement that says port-to-port data flow must be
>>>XML.  Instead, use some phrase that means "serialized data instance",
>>>or simply "data stream", a serialization of some data format specified
>>>by W3C.  (Actually, why shouldn't this just say "behave as if ...",
>>>instead of specifying the data stream?)
>>
>>
>> How would this expand its scope or power? Do you have in mind a
>> specific example of a use case that would be possible if the XML
>> constraint was relaxed but is not possible without relaxing it?
>>
>
> No, I don't.  I can only say that more options are better than fewer
> when there is little cost to the more.  And, although never
> impossible, it is usually burdensome to serialize and deserialize
> logic statements to and from XML.  This just raises the barrier to
> semantic processing with xproc.

Well, perhaps, but in this case, I think the cost of having more
options (the interoperability problems, definition of the mechanisms
by which options are recognized, etc.) outweigh the benefits. But
we may simple disagree on that point.

>>>2. Provide a type-checking mechanism on input ports to report a
>>>dynamic error when a port receives data it can't handle (instead of
>>>just XD0001 non-xml).  This could default to XML.
>>
>>
>> Allowing non-XML data would certainly introduce new interoperability
>> issues.
>>
>
> Very few.  Associate an "allowed-types" setting on each input port
> (default to "text/xml").   Associate a "types" setting to each output
> port.  Then you could statically check both for pipeline sanity and
> implementation capability.

That's the bare minimum necessary to achieve interoperability, but it
doesn't guarantee it unless all implementations are required to
support all allowed-types (even assuming a list of "all" could be
constructed).

> Yes, this allows people to write xproc scripts that use flow types
> that aren't supported in all implementations.  But if you limit the
> capabilities of the language, implementors will add non-standard
> features that render the xproc scripts non-portable anyway.  Better to
> provide a standard optional-feature list that implementors can
> implement and xproc writers can write for.  Maybe a "type-implemented"
> boolean function.

Better I think to encourage a small set of standard mechanisms.
Again, we may simply disagree.

>> I don't think the WG will consider expanding the scope in V1, though I
>> suppose it's a possibility in some future version. However, it will
>> have to be motivated by use cases that are prevented by the current
>> constraints.
>
> My personal experience when learning a pipeline framework was that I
> quickly dreamed up new applications that were beyond the capabilities
> of the framework, and were probably not among the use cases considered
> by the framework designers.  But I wouldn't have thought of these
> applications unless I first learned the framework.  For an enabling
> technology like this it is impossible to enumerate, _a priori_, all
> the problems it will solve.
>
> I think you have a genii in a bottle here, and I'd like to see him
> come out in V1 rather than later.

Indeed. But on the other hand, I want to make sure that the lamp is
small enough and light enough that everone picks it up and tries his
or her hand at rubbing it.

Undoubtably, users and implementors will dream up uses beyond what
we've considered. No amount of engineering can prevent that (nor would
I want to!)

If XProc is successful, we'll be able to revisit these issues with
real world examples to guide us towards where additional
standardization would be useful.

>> I remain convinced that some RDF steps would be (will be!) valuable in
>> XProc, but aside from p:sparql, haven't heard any specific
>> suggestions.
>
> See my "rdf processing steps" submission to this list.

Yes, thank you. I sent my previous reply before seeing that message.
I have, as you suggested, sent mail to the chairs of the SWD WG asking
for their input.

> Thanks for your consideration,

And thank you for your thoughtful comments.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | There is no such thing as an absolute
http://nwalsh.com/            | certainty, but there is assurance
                              | sufficient for the purposes of human
                              | life.--John Stuart Mill