W3C XML Processing Model Workshop

Cambridge, 12-13 July 2001

1. Attendance

The following were present on 12 July 2001.

2. Thursday morning

[Notes for this session by Norm Walsh.]
Attendees:
  • Daniel Veillard
  • Michael Sperberg McQueen
  • Henry Thompson
  • David Cleary
  • Richard Tobin
  • Asir Vedamuthu
  • Eve Maler
  • Jonathan Marsh
  • Dan Connelly
  • Paul Cotton
  • Steve Zilles
  • et. al.

2.1. XML Processing Model Thoughts; Paul Grosso, Arbortext

XML 1.0 does not concern itself with a processing model.
Infoset can be used (are a place to start) to define what gets passed from one step to another (but there are limitations).
Infoset creation always performs namespace and xml:base processing.
After you've got one, there's a lot you could do: validation, xinclude, xslt, query, linking, serialization, ...
XML 1.0+Namespaces+xml:Base -> (schema|xinclude|xslt|query)* -> (serialize|other-final-processing)?
Is the middle set recursive? No, this is the document infoset, the processing for the W3C XML Schema document etc., isn't in this graph. So this is effectively a three-dimensional graph.

2.2. Possible Questions/Issues

How do XLink/OnLoad links fit into the picture?
How should conditional XIncludes work? (We don't have them yet, but some folks want them.
Do we need to have conditional logic in the processing model?
What kind of process drives the processing model?

2.3. XInclude and XML Processing; Jonathan Marsh, Microsoft

Syntax description. XInclude processing is defined in terms of Infoset transformation.
XSLT processing is similar.
Most common use will be to perform XInclude before XSLT. Neither XInclude nor XSLT introduce interoperability problems; but the combination may.
XInclude could also be performed on the stylesheet that is input to the XSLT processor.
XInclude can also be performed after XSLT.
There is no general, default processing model that would work for all cases.
XML Schema processing is is similar: Infoset in, PSVI out.
XInclude may occur before W3C XML Schema validation. Neither XInclude nor W3C XML Schema introduce interoperability problems; but the combination may.
The same questions that arise for XInclude also arise for XML Encryption/Decryption.
XInclude may come after XML Schema. Main questin: what is the output of an XInclude processor that is given a PSVI? Is it another PSVI or is it a simple Infoset.
If XInclude does produce a PSVI, what schema does it correspond to?
W3C XML Schema processing within XInclude (if an XInclud*ED* document is run through W3C XML Schema processing before including): what is included the PSVI of the result? What is then the result after inclusion?
XInclude and SOAP: a SOAP message path is similar to an infoset pipeline: SOAP->Intermedaries->SOAP->Receipient->body
If all XIncludes are resolved at the beginning then none can occur in the body which seems problematic. SOAP is an example of an application where interoperability is very important and it makes sense for SOAP to be able to define a processing model for each step.
While a global processing model is not possible, it is going to make sense for applications to define processing models for their applications.
We may need to broaden the scope to include orchastration of business processes and then see if a subset of that solution will work for the infoset processing model.

2.3.1. Conclusion

A default processing model is insufficient
Applications need freedom in defining their processing models
Classes of applications may constrain processing models
XInclude is getting a bum rap.

2.4. Open Discussion

HT: Suppose I write a schema that references the xml:base attribute and gives it a fixed value. If xml:base processing is part of fundamental processing them it's not clear that this will have the desired effect.
CMSMcQ: I'm not sure there is a clear desired effect.
DCleary: We can simplify this by making infosets read-only; any process that changes them creates a new one.
DV: A generated document doesn't have a base URI. So a relative URI reference in an XSLT generated document should be illegal. There will be vastly more extended infosets in the next few years. Accomodating the PSVI as a specific case is insufficient. We need a single, clean solution for this problem.
HT: There is a long-standing dissatisfaction with the XLink recommendation because it does not successfully grandfather in all the preceding linking constructs (of HTML, SMIL, etc.). These specs use an unqualified href attribute which are compatible but you can't leverage XLink. The compromise that has been canvased is that the Infoset will will devise one or two new infoset properties and these will carry the linking semantics. And these properties may arise in the infoset in many different ways. Allowing SMIL to define those properties with the unqualified href attribute. XLink can do the same thing.
HT: I see it as a requirement that a solution we arrive at here supports that.
RT: What you've lost when you do a transformatin is the URI, not the base URI. It does not have a URI, but it may still carry a base URI with it. And those two issues are not the same.
CMSMcQ: One reason that things look simpler if you imagine reserializing and recreating an infoset is that you know the new infoset has been purged of all the extensions that used to be in it. And you know that all the derivitive properties within it are consistent. We can generalize this by saying that there are II and P that are derived. And you can say that in a transformation if you change a property that has things derived from it, everything derived from it has to go (there are levels and all things at level N+1 have to go away if you change things at level N).
RT: What happens if you go the other way around? Changing the in-scope namespaces without changing the namespace attributes.
CMSMcQ: Maybe that shouldn't be possible, and if it is maybe the answer is to write a process that can do the minimum amount of fixup necessary.
AV: [minute taker's gloss] Applying some processes, such as schema processing, repeatedly may not result in a meaningful infoset if the result is passed to a query processor.
SZ: I've heard two answers: one is that you can do it multiple times and you get different annotations the other is the answer that CMSMcQ gave, the second process would delete all the former properties so you couldn't tell.
EM: I'm concerned: it's not so much transformational technologies that bother me, when you move things around, but instead when you add new kinds of II and P. I'd feel a lot more comfortable if we were always able to reserialize it.
JM: Infoset additions should either be self-contained or identify the set that is self contained. It would be useful to know about those so that we could transform them. In-scope namespaces are nice, because they travel with the element. Lang is harder because it may be inherited and moving an element may not do the right thing. It seems that some simple things should be copyable (this is an integer), while others (the set of schema components) are much harder/impossible.
SZ: Identifying what, for any given property, are the dependecies needed to compute that property would make it easier to make understandable changes.
JM: Some things, like the whole schema component hierarchy, are not possible to preserve.
DC: The infoset spec has an RDF schema that allows you to serialize any augmented infoset. Serializing these infosets has also come up in schema conformance analysis. Also, it would be nice if all of the property names and other algebra bits, could be given URIs so that they could be compared.
RT: The serializations that result from these efforts are often very verbose. We have to consider if we want to find some serialization that's closer to the original XML document. Sooner or later we'll have to do something like that.
HT: There is a terminological confusion that we are stumbling over. There is a distinction between a serialization of an infoset and a reflection of it. [minute taker is not sure this is captured properly]
EM: The RDF-serialization is not what I meant, I meant something like the original document. Pure round-tripping would never be possible.
PC: An interesting criteria for query is will we be able to answer the simplest query, "/", to return the input document. The principal of least astonishment should apply. You probably can't get the real input document, but you should be able to get the same thing twice if you do the "/" query.

3. Thursday morning, cont'd

[ Notes for this session taken by Philippe Le Hégaret.]

3.1. Presentation by Paul Grosso

Paul Grosso
[slides at ?!?]
  • The Basics
  • XML Infoset
  • Generating the Initial Infoset
    • namespaces and xml:base should belong to the basic XML processing
  • Modifying the initial Infoset
    • validate
    • Xinclude produces a new Infoset?
    • XSLT produces a new Infoset (difference between new and modified Infoset)
    • if the result of a query a new Infoset?
    • XLink
    • serialization of the infoset goes back at the beginning.
  • The flow of the processing Model 
     XML 1.0+namespace+xml:base
    (schema | xinclude | xslt | query)*
       (serialize | other-final-processing)?
David Cleary: is your model recursive? schema are infoset too.
Paul Grosso: don't show in this draft. this is a 2D draft but it should be 3D. yes, it is more completed.
Joseph Reagle: xinclude also includes a recursion
Chris ?: you can start with an Infoset, not only angle brackets.
Paul Grosso: yes, you're bypassing some steps.
Paul Cotton: if this is your model, why core didn't define the reverse mapping?
Richard Tobin: we tried. how to do serialize an infoset in an XML 1.0 document?
Jonathan Marsh: we did have a cannonical in the core for a while. we passed it to the sign group.
Daniel Veillard: consider having an infoset compliant processor that doesn't generate any attributes. you might not be able to serialize it.

3.2. Presentation by Jonathan Marsh

[11:24]
Jonathan Marsh
[slides at ?!?]
XInclude and XML Processing
Is XInclude a low-level technology or higher level tech?
the processor model describes how to do it but not when to do it.
XSLT and XInclude 1) XInclude prior to XSLT not template in the XSLT to handle xinclude elements.
Daniel Veillard: you can have multiple sources. Jonathan Marsh: yes, this is a simplification.
2) XInclude after XSLT
XML Schema processing model
1) XInclude prior to XML Schema
XML Schema already have flexibility in choosing the schema, xinclude is just one more step.
XML Encryption/Decryption
2) XInclude after XML Schema
if we do produce a PSVI, what schema it corresponds to? (the current spec is broken) Jonathan Marsh: strip off the PSVI Dan Connolly: no, don't do XInclude after XML Schema at all. Paul Cotton: yes, if somebody includes more constraint in the infoset, it's even more painful.
3) XML Schema processing within XInclude
XInclude and SOAP
XInclude processed by each SOAP Actor? or just passed them along the pass?
Conclusion
  • a "default processing model" is insufficient
  • applications need freedom
  • classes of applications may constrain processing models.
  • XInclude is getting a bum rap.
Jonathan Marsh: I don't think there should be a default processing model. browsers and SOAP have different requirements.
Joseph Reagle: if you want this flexibility, what does it mean for signature? enumerated signatures?
Jonathan Marsh: in my model, as part of decrypting the signature, you can do some processing. gluing signatures as a whole block into the processing model.
David Cleary: I understand the position regarding "default proc model" what about a soap proc model?
Jonathan Marsh: soap will need to specify what the proc model
Asir Vedamuthu: what about proc model for an initial infoset? (reference to Paul Grosso)
Jonathan Marsh: good idea. I believe it's already builtin in the infoset.
Chris ?: I'd be careful about defining a proc model for SOAP. if you apply the signature proc model into it, what will happen? Several things apply in the proc model.
Jonathan Marsh: maybe layes of proc model. orchestrating all proc models. important to predict SOAP content with xinclude.
David Cleary: [...]
Jonathan Marsh: intentionally vague in that.
Richard Tobin: if you type a URI in a browser, same sequence should happen. there should be a default proc model.
Jonathan Marsh: I would say yes. but let's see interoperability problems. no browsers supports xinclude yet. user agent guidelines can defined that.
Richard Tobin: default proc model for specific application accepted by all applications.
Daniel Veillard: if it's only a xpointer defined proc model, but [should have a cannonical processing model]
[11:49]
Steve Zilles: is there consensus with the basic definition of namespaces and xml:base done?
Henry Thomson: supposed I write a schema which declared reference i the xml:base with fixed values, that fixed values won't have the desired effect. by saying it's fixed, it's done once.
Richard Tobin: do not assume this kind of processing is done.
Steve Zilles: that's a deployment issue.
Eve Maler: some confusion about xml:base processing. xml:base in the infoset doesn't mean absolutizing URIs. every transformation can mess up something not meant for that.
Michael Sperberg-McQueen: xinclude must change the properties of the formal parent. not only augmentation of the infoset. [reference to Henry example], don't think there is a desired effect.
Henry Thomson: just like xmlns in DTD.
Richard Tobin: // with xml:lang attribute.
David Cleary: different specs. creating, changing infosets. if you do a set of specs, creating a new infoset. if we don't put a rule to discard the infoset, we will not be interoperable. don't use schemas to modify an original infoset.,
Daniel Veillard: yes, you produce a new infoset, you don';t have a base uri for documents anymore. interaction of specifications.
Henry Thomson: pending problem: disatisfaction with Xlink, it is not used with others specs. SMIL uses an unqualified href for linking semantics, compatible with XLink, but cannot leverage links in a consistent way. the proposed solution is: we will defined infoset properties that will carry linking semantics, different ways to obtain them (from SMIL, XLink, XML Schema types, ...). A range of different processors are bound to a particular set of linking properties. it is a requirement that we provide the necessary for existing XML applications.
Richard Tobin: Daniel said "as soon as you transform the infoset, you loose the uri". you lose the uri, not the based uri.
Daniel Veillard: yes, but don't forget to propagate the base uri, otherwise, it doesn't work.
Michael Sperberg-McQueen: once you serialize and creating a new infoset, all the derivative properties are consistent. they are infoset items that describe core properties, others are derived from them (namespace in scope, ..). we cannot prevent for designing extensions to derive the properties. all the properties at level n+1 should be stricted for level n. being to regenerate the items.
Richard Tobin: [...]
Asir Vedamuthu: after you build the initial infoset, you can recursively apply xinclude, schemas, ...
Steve Zilles: two answer you can put multiple schemas on top of it.
Eric Prud'hommeaux: don't rely on transformation that augment the infoset, people will do it anyway. we should resolve the problem now.
Eve Maler: sympathic to Henry problem and fixing it. get nervous on adding new kind of items in the infoset. not just transform. feel more comfortable if we are always able to serialize it.
Jonathan Marsh: one of my wishes, as more as we advanced, more restrictions will be added on the infosets. in scope namespaces, you just copy across with xinclude. copying all psvi includes more meaning, let the application do that.
Steve Zilles: identifying what for any given properties, the dependencies should be identified and need to understand how to recompute them.
Jonathan Marsh: the schema hierarchy might also need to be recomputed.
Dan Connolly: serialization of the infoset. the infoset has an RDF schema that actually works, even with addition. names for PSVI that are not uris. same of xml query. if you give them uris, then you can serialize them in rdf.
Richard Tobin: there is also a xml schema to define the serialization of the infoset. every character turns into an element. should we consider to serialize as closer to the original document.
[steve closes the queue]
Henry Thomson: distinction about a reserialization of the infoset, and a reflection of the infoset. it's one thing to go back to the serialized document. other thing to produce an xml representation of this infoset. that needs to be distinguish from a strict reserialization.
Eve Maler: had in mind: vaguely similar to the original document. pure round tripping will never be possible in any case.
Paul Cotton: criteria for queries: will we be able to do that? I would like to be able to get the original document after the processing model. I expect that the second time, you'll get exactly the same thing.
Steve Vernon: preserving the extensions: if you take arbitrary extensions, unless the things are self describing, we cannot know what to do (should you relay them?) it needs to be in it, not external.
Steve Zilles: whether there is an initial infoset or not, i think the answer is yes.
[12:30 adjourned for lunch]

4. Thursday afternoon

5. Friday morning

[Notes for this session by Mark Nottingham.]
Minutes - 2nd day
Eric Miller presentation -
Arnaut - today, every wg seems to assume that they're the last one in the pipeline. before we specify a mechanism to allow ordering, we should make it possible to have any ordering

5.1. Group 1

* Group 1 (christopher ferris) use cases
  • xmlp
  • browser
  • arbitary pipelining
success criteria
  • is a process language or notation important? yes, may already exist
  • conformance; for process modules. important for input and output infosets to be described, as well as constraints should be applicable to external process modules
  • serialization of the infoset
  • substitute/reinforce the transforms in XSLT
  • able to sucessfully describe current processes
order of XML documents in general
  • partial ordering can be set in stone (paul's presentation)
  • generate primordial infoset, then apply application process modules
  • same applies to order-specific document
user control
  • yes, depending on who the user is (end user - grandmothers, power users ability to control processing, developer or engineer should have full control)

5.2. Groups 2 and 3

* Group 2 / 3 (jonathan marsh) - discussed Web Services and browsers
use cases
  • go to a uri with an xml file, it should just work
  • rdf/xhtml problem discussion - specification model problem (embedding rdf in xhtml - xml base isn't rec'd by one)
  • invoice doc that uses xInclude to suck in parts, then a schema that is applied to give each part a key - would be helpful to have a mechanism (in schema? to indicate ordering)
  • pipelining xquery model together with DOM - editing application. Are there data model issues that impact the processing model?
specific ordering
  • no single order possible
  • would a default ordering be useful?
  • certain pairs of processors have a natural order - might be good to indicate in specific specs, thereby letting a default processing model arise
    david orchard: would this require each spec to be aware of "previous" spec? jm: temporal order of publishing is controlled. david veilliard: not previous or next, just before or after do: if we wanted to insert a new spec in between, we'd have to revisit jm: not necessarily ??: making a "soft default" chair: an attempt to create a common understanding richard tobin: not "this process comes before this process", but "this process requires this information/processing to be available" steven vernon: ordering is dependant on context steve zillies: clearly documenting what information a spec expects to be available is very important paul cotton: give a clear definition of what has to come before you if you're last in the pipeline. If I'm not last in the pipeline, what needs to be considered by a spec after me? we have to consider that if you do xinclude after schema, you have to consider impact on PSVI - do you have to run a schema processor again? If we don't do this, we continue to assume we're last in the chain. )
    any specific ordering of xml processing which always appli: es?
    • no
    is it useful to include info in the document re: how it is to be processed?
    • most thought yes
    • environment might override this
    • application may override this
    is it useful to allow users to specify ordering?
    • most say yes
    question 2 (david cleary)
    • two things required
    • by querying the base infoset, what has happened to it?
    • come up with rules for when one process changes the base infoset or extended infoset, what happens? consider information consistency / damage
    Steve Tolkin: something important seems to have fallen through the cracks
    • processing model
    • data models (four identified) - mismatch about expectations
    • specification model - as specs evolve, problems occur (evolution)
    • all three form an end-to-end solution
    eric miller: agreeing that the infoset is what passed from process to process
    paul grosso: each spec should stand alone, shouldn't talk about what other specs do. It's OK to talk about relationships
    david cleary: i'ts easy to talk about infosets, in reality, you're passing around more concrete data models.
    ??: observation - xquery data model is based on infoset and psvi, but different than psvi because psvi is layered upon vanilla infoset; will this cause probelms? philosophies are different
    chair: doesn't elbow its way in - it's just "by the way..."
    ??: data model goes a lot farther in elbowing in
    paul cotton: in query, it's not the case that you get infoset or psvi; query needs types. Query will infer types in the absence of a schema. Jonathan is making the point that you get more than the infoset.
    steve zillies: another aspect to infoset data model - xpath/xquery data model abstracts some things that are primitive in the infoset; they're no longer primitives; I get type info, but not in terms in psvi; I get a reduction of that. purpose of data model was to solve problems at hand (language being constructed). DC points out often that xpath data model has text nodes not character nodes; this was done purposefully to push a string matching model vs. a character matching model. Taking the the data model and serializing it won't give you back the info in the infoset.

5.3. Presentation (PLH)

Presentation by Phillipe Le Hégaret.
steve tolkin: is it possible to serialize with load/save? (yes)
chris ferris: multiple doms all operating, seems like a database - seems like it requires implementation a database. (no, we explored this - don't need a db.)
arnaud le hors: options we provide to allow app to tune what is loaded; the more we add, the more complex it will become
chair: observe with concern the infoset you get from an XML1.0 processor is unstable; why did the solution that WG provided for that (stand-alone) not have the desired effect? Is there a lesson for us there?

5.4. Presentation by Steve Zilles

presentation by steve zillies
chair: question of clarification re proposed API: if the embedded processor knows enough about a property to ask for its value, how can it not know if it's inherited or not? (lower-level embedded processor; "tunnelling")
daniel v: in SVG - rules which apply to top-level XTML document must be applied to embedded documents; it's not the same document. (rules that HTML defines augment the existing properties and augment the local properties) If you have a rule which applies at the root level, you have to reapply
??: XLINK - when you embed something, it has its own stylesheet
dv: different cases might not be the same - not clear
steve vernon: we've been assuming that processing is on infosets - this shows there's other info passed between processors - we need to not just focus on the infoset. There also may be multiple infosets interacting
sz: stylesheet and xsd are XML themselves
richard tobin: xslt2 might have something that triggers xinclude processing; you were talking about styling doing processing. both seem to presuppose an answer to the question of where is the location of the processing model? A separate program that controls the order of these things? You speak as if this is already decided (personal view; in this case, processing steps should be specified in-spec; "natural" place - unless I need to force interfaces between these steps, unless there is a strong requirement for these interfaces)
chris lily: stylesheet assumes that something has been done. css has recently decided that "it's all happened"
chair: once again, "we're last in the pipeline"
jonathan marsh: xslt transformation within the styling module rather than as a separate step (didn't say what was happening; unless there's a need to break out the internal interface, let's avoid it)
** break **

5.5. Breakouts

Second session was breakouts?

6. Friday afternoon

[Notes for this session taken by Joseph Reagle.]

6.1. Attendees

6.2. Reports from Breakout Groups

  1. [SZ] Did a better job at defining problems then coming up with solutions. Eve suggested on focussing on concrete scenarios.
    Browser scenario: you've received a document based on a request, what kind of processing needs to happen. Started with complex document, but then decided to move to simple problem -- which we never got beyond.
    Document with an XPointer and Xinclude, which version of the "document" does the XPointer refer to? There's a number of resources depending on your expectation of processing.
    If I ask for the the 3rd paragraph of a document with a single paragraph and XInclude with two more, which is it that I get?
    What presumptions should XPointer make, has schema or XInclude been done already? Group felt that XPointer didn't imply processing.
    [EM] XInclude imposes an interpratation on XPointer. A future version of XPointer could have schemes about what versions of the document you are processing into, as part of the expression.
    [SZ] We then looked at whether you expected the server to do processing or not. Have to look at the MIME type of the document. You can't trust someone who says Xinclude was done if XSLT was done in between, as teh stylesheet might have introduced new XIncludes.
    [JR] As aside, to avoid these ambiguities, in Signature we don't recommend people put XPointers in the URI itself, but list them as explicit, ordered transforms.
    [EM] I was wrong in the break-out, the HTTP just returns the content, so ID and XPointer are done on the client.
    [SZ] Didn't follow up on the idea of a request parameter, though, as mentioned, it's possible in the next version.
    Problem in writing out the fragment identifier
    It's up to specifications that use XPointer to specify what happens before the fragment identifier is applied.
    1. XInclude does this for it's XPointers.
    2. XLink might have a default processing, that could be done in a future version, but other users of XLink could augment or over-ride. What semantics should XLink specify, or what should the application do?
      Chris Lilley point out a link like document in SVG.
    Strategies for documenting assumptions of processing order: put it in the document; speak only of what information must be available for subsequent processing, this allows you to be agnostic on the processing as long as your requirements are met.
    [DV] When you are just trying to ?save? an XML page, should this be part of next step.
    [SZ] We agreed that there was no agreement on what the result of a fragment identifier is.
    [CMSMcQ] I thought it was based on the MIME type.
    [SZ] Yes, but the application itself
    [EM] This is related to the mismatch between XML and MIME types, conceptual or even temporal. ([CL] HTML/WebCGM/SVG have well defined fragments.)
    [RT] We asked TimBL if what XInclude did was ok with respect to his concept of a fragment that you put in your pocket while you figure out the MIMEtype.
    [JM] ?The question of processing an XPointer before figuring out the MIMEType of something was still open.?
  2. [EM1] Web Services group was all over the map. Got lost in trying to define what a web service was.
    As XML specs converge, we need additional rules, somehow, somewhere, on how to compose the processing.
    Specs need to better define their relationships: what you do with an InfoSet (input/output) but how robust you are.
    If there is a language, if it's mandatory or advisable, even if optional they'll still be a strong mark push for implementers to comply.
    WGs should not think they are the last in the pipeline.
    Is coordinating the relationship between communicating agents similar or different than the description of the processing model: not clear.
    [?] Action item to propose preconditions and postconditions and communicate on the list. David to send his thoughts on guidelines for specs to the list. Also a call for straw man proposals: if you know what you want to do, show it working in SOAP.
    [JM] The idea that WGs should be more aware of other WGs, this is motherhood. Paul Grosso stated it well in that each spec needs to fit into a composable model. Good idea, but not even sure how to do this with Schema since they invented a bunch of augmentations. If people do continue to extend, we could use guidelines on how to compose with those extensions.
    [PC] Question: who else is extending the InfoSet. [EM] Linking and Styling proposes a way in a NOTE.[DV] Yes, it put a marker within the InfoSet. Yes, I mentioned schema extended it, but don't want to advocate everyone doing extensions necessarily. [JM] DOM has many properties not in InfoSet, and its terminology implies that it isn't exclusive.
    [EM] The developer community railed against the PSVI, but because maybe it isn't well specified; if it was, maybe it'd be better received.
    [MSMQ] The answer from Core about the Schema request was "No, the InfoSet does XML+NS, not anything more." Don't want to update the InfoSet spec with every change.
    [CF] Already having problems coordinating a handful of specs within the W3CF What happens to everything outside of W3CF If we don't solve the problem such that our handful of things work, how can we expect the myriad of internal/external to interoperate? Web services will raise this issue in a big way. Some ability to describe the processing, be the post/pre-conditions or what might have been invalidate, with respect to our core/focus, needs to be done.

6.3. Straw-polls

  • [CMSMcQ] (Slide reiterating purpose of Workshop)
    (Slide on desired outcomes)
    (Slide on Ordering)
    • Consider [PG] trio of XML parsing, Namespace identification, XML:base calculation.
    • No InfoSet before they have run.
    • No need for user control.
    • Let's call this bootstrap processing, everything else is application processes.
      [PC] Is it possible to create an InfoSet with literally running these processes. [CMSMcQ] Yes, "de nova" creation would also be part of bootstrap.
      [?] Has everyone implemented all of this triad, are we sure about xml:Base?
      [AL] You may be right, but these are standardized in InfoSet.
      [CL] An application needs to decide whether it wants to use xml:Base.
      [RT] What is described there is the canonical way of obtaining an InfoSet by parsing an XML document; though not the only way..
      [JM] Clarification: xml:Base has to purposes, to provide the syntax, and to provide the base for use within the document.
      [CMSMcQ] Three questions, where do XInclude, schema, and XLink fall?
      [JM] didn't you just define as these things as app? [CMSMcQ]] No, I defined bootstrap is the initial over which users have no control in ordering.
      [DV] You defined bootstrap as no InfoSet before processing, for these you need an InfoSet.
      [CMSMcQ] Clarification, not the case that there is no InfoSet, but nothing that we'd want to see or control.
      [ST] Might be unhappy because this seems like an exclusive-or. I want XInclude to be bootstrap and I want to be able to use it later. Second, Guessing that you are saying disregarding the context, please vote.
      [CMSMcQ] Bootstrap things have to happen regardless of the scenario. Not excluding from doing it again.
      [PL] If we declare XInclude in the bootstrap, what happens to XSLT1.0 or SMIL1.0, would we declare them invalid?
      [CMSMcQ] This is a workshop, trying to understand what you want, can't dictate to the world.
      [CMSMcQ] How many think XInclude should be bootstrap: 2+DanC in abstentia. How many think XInclude is an application choice: 17.
      [DV] not a bootstrap because assume you have an XSLT, you might want to work on it.
      [CL] I think of XInclude as a better replace for external entities, should be part of the parser.
      [RT] I also think it's better, one of the ways it's better is that it's not confined to bootstrap! <laughs/>
      [CMSMcQ] How many people would like schema validation to be bootstrap: 5. How many people want it to be an application process: many.
      What bout XLink (actuate onload) Bootstrap: 0, Application: many.
      [JM] The vote we just took is informed by our two days of discussion, but we'll still have to speak to the outside community.
    • Question on Ordering: (Under what circumstances does it make any sense to say anything about ordering). Ordering over current and processing modules/specs.
      Does it make sense to take about ordering all documents, those in one processing scenario (browsing), or all elements in a NS, processing episodes in a document.
      [EM] In one namespace, I think should it have one process/application relative to others.
      [SZ] XInclude is in another namespace, so not sure if I understand.
      [DV] Problem is that question 2 (processing scenario) is dependent on whether it's on the Web.
      [DO] Short on time, could we ask these questions of other WGs, or focus on a resulting action.
      [RT] 1. No, nothing can be said about ordering all document.
      2. Yes, because I think there's a default processing when viewed in Web browsers.
      3. Yes, because I think there's a default in a XInclude, but it's only a default.
      4. Yes, because I'm sure there's some folks with a default sequence in mind, but it's not the only one.
      [Reagle] Who agrees with Richard.
      [PC] Richard, your answer on the 4th presumes ...
      Question at large.
      1. No.
      2. Yes.
      3. Some yes, some no, a couple don't understand.
      4. Numerous yes, 3 no.
    • Ordering [these questions are a matrix with the previous slide]
      1. Fixed:
      2. Partial:
      3. No universal order:
      4. Default order:
      5. If so, what's default.
        1. If no instruction otherwise, do XLink onload before schema
        2. Non-normative appendix with an expectation that this is the normal.
    [SZ] Default only makes sense if you can also explicitly specify otherwise.
    [CMSMcQ] Any cases where an absolutely fixed order makes sense over bootstrap *and* application. A few (signature), partial: some, no universal order: some.
    Do people see cases where there should be a default but over-ridable: many.
    [CMSMcQ]: If someone does other than the specified, is he non-compliant?
    [JM] Depends on the class of the application. Shouldn't be a default amongst all XML specs, but within an application, it should be able to specify.
    [SZ] It must be normative, if it isn't then I have to explicitly specify every time, in which case it saves me nothing.
    [CMSMcQ] Some people here think the order should be be normative per application, I heard otherwise in hallways.
  • Scope (not exclusive)
    1. full orchestration: 11
    2. dependency/constrain language ([SZ] alternative forumulation: could have this on a state of data, exit/entry conditions): 17
    3. simple linear flow language (like Signature):15
    4. nothing: 3
    Used for (not exclusive)
    1. controlling processing (what must/should/is expected to happen)(make it happen): 19
    2. documenting processing (what must should/is expected to happen): (in a spec, or carried in a doc): 15
    3. document processing (what has happened) (in a log): 15
    [CMSMcQ] Current population of room is 32.
  • Venue: if we do this work, where? (preference, pick 1)
    1. XML Core: 15
    2. XML CG: 1 ([EM]: other coordination issues need to take place, dependencies with semantic web need to take place)
    3. Wait for XML protocols to do orchestration: 0.
    4. inter-WG task force: 5
    5. new WG: 7
  • Open discussion for next steps:
    [PC] To take to the AC, maybe should be done as part of the rechartering the XML Activity, what should the new Core look like?
    [DV] Voted for Core because was sure if it was sufficient to create a new WG. but the Core has a lot of work, hard to do more than two things at one.
    [EM] Even if we do nothing, we've come up with so many examples of things that can be cleaned up that Core could start immediately.
    [JM] People seem to assume that it's good to extend InfoSet, maybe some guidelines of what constitutes a useful extension.
    [AL] Agree with Jonathan, wonder if we need to define a generic extension mechanism in InfoSet? DOM could specify the API for these extensions in a generic way.
    [SZ] Just in case nothing happens before next spring, there's is another Plenary is the process of being planned then: summary/conclusions for that meeting would be useful.
    [ST] I think there's a serious problem, lacking a really good problem statement, could someone write the paragraphs, that'd be helpful. Design by committee is awkward, having the W3C get an architect to come up with something. [Others] the TAG could do this. [Others] this is Tim's job. [ST] I stand by my request.
    [DV] I have a problem statement: when will we serve XML from a server directly to the client? This ambiguity (of the workshop) prevents us from doing this well presently. If we don't define a processing model for this specific use, we've spent three years on nothing since this is something we worked towards.
Close and Thankyous.