Re: Open Step Library Issues

/ Alex Milowski <alex@milowski.org> was heard to say:
| In no particular order:
|
| 1. boolean option values - 'yes|no' versus 'true|false' ?
|
|   We have steps that have options that use 'true' and 'false' values
| and we have one ('status-only' on http-request) that uses 'yes' and
| 'no' values.
|
|   We also use 'yes' and 'no' in our specification.
|
|   Doesn't it make sense to have these all in sync? Also, shouldn't we
| be use an XML Schema simple type (e.g. xs:boolean) ?

I could live with allowing true/false, but I'm not a big fan. I insist
we allow yes/no to be consistent with XSLT and I have a preference for
only allowing yes/no.

| 2. Add a 'content-type' option to the p:unescape-markup step.
|
|   This option would accept a media type. If the media type is
| recognized by the processor, parsing according to the media can be
| performed and that behavior is implementation defined with the
| exception of any XML media type (i.e. text/xml, application/xml, and
| *+xml types). There is no default value and the step assumes XML
| parsing without a value.

I think the default should be "application/xml". I also think that we
should enumerate the content types that processors MUST recognize.
I suggest: application/xml, application/*+xml

| 3. Wrapping a sequence:
|
|   Do we want a separate step type?

I'm ambivalent, but either way we need the functionality. It might
make sense to wait for Henry's grouping proposal to see if it makes
sense to default to sequence wrapping or not.

|   Should the 'name' option name be changed?

Yes.

| 4. Http-request review
|
|   - header conflicts

That may just be an editorial request for clarification :-)

|   - invalid method creates a dynamic error

I think it should.

|   - href uri isn't a HTTP-based protocol (allows for https)

I think that should be an error too.

|   - multiple bodies is now handled by multipart:

Good.

|   - making it required

Yes.

| 5. Should we rename p:xslt to p:xslt1

/me shrugs.

| 6. p:load options 'validate' and 'namespace-support'
|
|   The 'validate' option would control DTD validation.

Yes.

|   The 'namespace-support' would turn on or off namespace processing.

Yes.

| 7. p:escape-markup issues?
|
|   - Given a match pattern via an option called 'match', it will
|     escape particular elements (e.g. the RSS description element).

Yes.

| 8. p:aggregate again
|
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0229.html

I think this is the same issue as 3.

| 9. General validation
|
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0225.html

I don't feel strongly about this. I could support optional
p:validate-schematron (though I think the reference implementation is
actually an XSLT stylesheet, isn't it?)

I can't say one way or the other about p:nvdl until someone writes up
a concrete proposal explaining how it works and what it does.

| 10. split-sequence
|
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0171.html

This looks like p:matching-documents with a secondary output port that
receives the *non* matching documents. I guess that makes sense.

| 11. count/tee proposals
|
|  - Should tee be removed now that we have journaling ?

Yeah, probably.

|  - Should count remain?

Yes, please.

| 12. p:save/p:serialize proposal
|
|  This is part of the forthcoming proposal on serialization.
|
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0139.html

I think that deserves its own thread :-)

| 13. p:label issue?
|
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0087.html

I suppose an optional "match" option would be ok.

And yes, an implementation that generates a constant xml:id value must
fail if there are two elements in the document that don't already have
xml:id values.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Life always comes to a bad end.--Marcel
http://nwalsh.com/            | Aymé