See also: IRC log
<scribe> Scribe: Rhys Lewis
<scribe> ScribeNick: Rhys
SW: Notes the regrets and TimBLs possible regrets
... Notes that the agenda has been reordered to accomodate Dave's timetable
... Notes that some items may be at risk because Tim isn't here
... Agenda approved
RL: Minutes from last week: http://www.w3.org/2001/tag/2007/10/18-minutes
SW: Minutes from last week approved
SW: Next call November 1st, a few days before next F2F.
... Notes that call will be at 5pm next week because the clocks change.
... Asks for regrets, hears none.
... Resolved to meet November 1
SW: notes recent draft announcements that contain definitions of CURIE syntax
... Asks if anyone else has reviewed these
HT: I believe I read the last editor's draft of the CURIE spec. Just checking the version.
SW: I picked up the reference from an e-mail that is linked from the agenda
... I found a normative section that says that the syntax will be in a different document. I have asked them to remove that and clean up the reference
... Seems confusing to have this in a last call version
... There is an introductory paragraph that claims that CURIES are a superset of QNAMES. They need to make it clear that the syntax is a superset
HT: I've made this comment to them as well.
SW: I've pointed out that something needs to be done to XML schema types to accomodate CURIES if they are to be first class citizens going forward
... The default, to be taken as the first part of the URI when no prefix is given, is in the XHTML namespace. I've commented that as the mechanism is general, this should not be hard wired to XHTML
... Also noted that the text in the RDFa spec is more mature and does not indicate the intent to pull it out into an external documet. These need to be consisten and we need to know what the intent actually is
HT: I also noted that the BNF has often been in error in the past. It still looks as though there is a problem in the first production.
SW: The production in RDFa is different.
HT: I think the RDFa version is the one we agreed.
SW: They also don't seem to have an expansion of basecurie.
HT: There is no basecurie in the draft I'm looking at.
... The RDFa one seems to be the one we should be looking at.
SW: I agree, but that makes it hard to comment on this particular document as a last call.
... Should I send in my comments, or should we produce a TAG position?
HT: I think you should send personal comments, because TAG comments should be at a higher level
SW: Could you expand?
HT: I'd rather wait until Tim and Dan are here before discussing what are really their views.
SW: Noah, do you have strong views about another syntax for writing down URIs.
NM: Henry, you feel that this is not the appropriate thing to do?
HT: I'm not convinced this is the right thing to do.
NM: Like Tim and others, I think alternate representations for URIs are in most cases harmful. If that argument doesn't carry the day, and if there really is a perceived need in this caase, then my intuition is that we should remind ourselves that we risk a proliferation of alternate formats.
... We already have URIs and QNames and now we have this new proposal for yet another format. I think we've seen other proposals too. If there is to be yet another an abbreviated syntax, it should be the last one for a long time. Are we convinced that this spec has this characteristic?
HT: I'm not aware of another effort in this area.
NM: I have a recollection of some other mechanism that I've seen, but I don't have the details to hand.
SW: I think we need to have Tim and Dan around for a TAG discussion. In the meantime, I'll make my own comments.
... I think we need to wait for Dave for TPAC and XMLVersioning
<ht> The URI, for when we get to it, is http://www.w3.org//2001/tag/2007/09/xhtml-modularisation-thoughts.html
HT: That is the document associated with ACTION-48:
... I've talked through this to section 5 when we've discussed this before. Schema 1.1 supports multiple substitution groups, but it's not clear that even this supports the requirements of XHTML modularisation
... Substitution groups are great for adding a few new elements to a language
... I believe that as far as the HTML WG requirement is concerned, if the default profile of the language doesn't allow button, it's treated the same as banana would be treated in the full language
... I thought that it would still be possible to create the modularisation in schema. In section 6 of the document, I outline the approach I used to try and make it work
... There is one schema document per module, and three driver documents. In the rewrite there ends up being one subdirectory per module
<Noah> Hmm: http://www.w3.org/2001/tag/2007/09/xmod/ gives insufficient access privileges
HT: In a module, there is a file called type that defines the types, and one file for each element.
HT: The list module turns into a series of tiny schema that each just say that a particular element belongs to a particular substitution group
... Near the bottom of this types document you'll see the xhtml.ul.content contains any number of list item elements
... Only via the substitution group mechanism do the elements get into the content model
DO: So you define the element, and then allow an abstract set of things of a particular type. Things at the bottom the define what goes into the particular type
NM: Is there something that controls which directories the schema processor looks in to find these?
HT: I'm coming to that. There is something in the document that ties this all together.
... The DTD uses parameter editing to build up the content for various elements. There is an equivalent hierarchy of substitution groups in the classical design pattern used for the DTDs
... Everywhere where there was a group in the DTD, there is an abstract element and a substitution group that populates them
NM: The change in schema 1.1 is that an element may say that it is in more than one substitution group
... What if I want to make a reference to more than one substitution group in the reference, could I use a choice
HT: You could just define additional elements in the substitution group
NM: Suppose that I invent a new version of HTML, and a lot of the rules are the same.
NM: I want to change some of the schema. The list rules are the same as for the previous version, but I change things around list. Does that mean I need to change every thing where the substitution group for list is used?
HT: Let's see if I can answer that from an additional driver document.
NM: my question was more to do with how much work is needed to provide a new version of a language
HT: Describes the relationship between the definitions in various files. There is a multi-step process for getting from the lowest level definitions to the actual content model for a particular group
SW: How do the names work to stitch this all together?
HT: This one has comments left over from the original. At the end, you can see the includes for each module and element that you want to include in the language.
SW: Do those do further imports?
HT: No they are all self contained.
... there are a couple of cool things about this. All you have to do to define a profile is just to remove some of the includes
NM: This is for the class of profiles that are the ones Dave mentioned.
HT: yes, and creation of profiles is really simple
NM: So if li is in multiple substitution groups in one version, but in one substitution group in another. Could I do that easily too
HT: No, because the approach I took was to reconstruct the existing design, which worked by putting li into a class.
... It's the class that gets into the substitution groups
NM: But it would be possible if I built a different language from the start. The basic mechanisms in Schema 1.1 would make it possible, just in this case we don't have that
HT: There are two benefits of this approach. One is that in defining the two profiles, and I was able to build 'basic' on top of the other one
... In the current 'basic' spec, they had to have a separate module definition. I didn't have to do that. I was able to subset them by removing the relevant includes from my driver. I didn't have to change any of hte include structure or any redefines.
... The second thing that was really easy was to define Japanese HTML with the new approach.
HT: I just needed to produce a document for each element, with a different, Japanese names. The driver just gets its elements from the japanese directory
... It validates
DO: One thing is that there are other use cases for profiling, other than for device targetting.
... In portals etc. they are subsetting HTML. For example, what subset of HTML is allowed in the comment field for a blog, or that Facebook will accept?
... I think there will increasingly be more subsets of HTML on the Web
... In those cases, there is no single root element for those subsets. Has there been any thought about schema without root elements?
NM: I expect that really there will be a set of root elements
DO: In Facebook you can send anything that can be a child of body.
NM: So in Henry's model, there would be a substitution group for that
NM: So I think that would boil down to a definition that they except anything that could be accepted by a particular element
... Schema itself won't validate a 'forest' only a tree
HT: The spec says this very clearly.
NM: We could have probably said that another starting point is the sequence of things that might be children of an element. But we didn't do that
HT: Not all of the bad news has gone away, however. There is no equivalent to the aggregation used in the old definition
NM: How about a last call comment about this?
HT: It's not trivial. At the moment, to get further than subsetting or simple extension, it needs the whole mechanism used in the previous approach, plus this approach to
NM: It would be great if we could publish 1.1 and get a 1.2 out with attribute substitution groups etc. It seems that this seems a really useful thing to do
... Is it true that you are assuming everything is coming from the same namespace
HT: I did keep one aspect of the original, which is that it's in no namespace. Validation does require that the schema parser allows the multiple headed substitution groups
NM: If we look at what people do today with Relax or NVDL would people like the new approach or would they be unconvinced
... Think that people would find these useful.
HT: If I'd done this earlier, then this problem might not have arisen
SW: Is this suitable for publication?
HT: I should send it to schema WG and XHTML WG. As far as its relevant to the TAG's versioning efforts, it is a proof of concept
... We have evidence to support Dan's desire to see something like this. I'm not sure what he would want to do as a follow up.
NM: What if we just pushed people to use it. We could put a requirement into schema 1.2 to make the additional changes. Is there a chance we could get the rest done?
SW: Are you both still active in the schema working group.
NM: They are in last call just going to CR.
DO: I don't think LC means that if a major problem comes up, it's too late. There often is resistance to fixing things
NM: That's partly why I pushed on this. Henry noted that this is one of those things that could be difficult to put in
... There is another side to this, because of the small size of the group.
SW: I didn't mean to go to the schema group saying we need to do the additional work, as much as saying look what you can do with this, and it's a pity that there is a bit missing
<Noah> I sure wish there was a way to show that doing attribute substitution groups wasn't too much work, and just get it out ASAP.
<Noah> I think Henry's demonstrated that we're 85% of the way there to something really cool in Schema 1.1
<Zakim> dorchard, you wanted to mention some use cases and to ask about top level root or not? and to talk about multi ns
DO: Noah hit on the point about namespaces. The extreme end of versioning is where every element and attribute is in its own namespace. We need to think about supporting this sort of thing.
... Once there are two namespaces in a documnent (XHTML/RDF) it's about the same as where there are lots
HT: Actually its trivial. I should have given an example of adding material from other namesapces. There is the import issue, but it's not a serious one.
... You just define the little schema document to define your elements and specify the substitution group to which they belong.
SW: Henry, would you like to have this marked as done? Or should we wait until the chance to talk with Dan and Tim
DO: How about updating the schema 1.1 guide to versioning?
NM: There may be an issue of the size of the document, since part of it would be a set of neat tricks and another would be a particular solution for a versioning problem.
SW: We have one more item under this item
NM: Yes, and it is on my queue to do. I need to learn the formatting stuff.
... I've been somewhat nervous about the material being in the middle of the QA material. I was waiting for a decision on whether the blog is sufficiently stable for us to use
SW: Yes. One of the things that made me slightly more happy was that QA is now Q and A
NM: I don't want to find that in a few weeks we move to another blog.
HT: Actually, if we do change things and have different skins in future, only the look and feel would change. The URIs would be the same
NM: I'm wondering if I should put the blog ahead of the self describing web?
<Stuart> http://www.w3.org/2001/tag/2007/11/05-agenda18:30:30 <Rhys> SW: There is more than half a day's material for the first session. For the Friday, we have Stuart, Tim, Rhys, Dave, Noah
SW: I'd use that time for items we've not completed from Monday, a joint meeting with HCLS
... Doing that joint meeting on Friday could work. Don't want to prevent Henry attending.
... Could be 9-11 on Friday morning. And then not do Thursday evening
RL: +1 to that
Discussion ensues around when we might have the joint meeting
SW: I need to know who could be present for the joint meeting with Web security
Henry, Dave and Noah confirm their intent to join.
Rhys needs to check because there are other groups meeting on the Tuesday.
SW: Let me know of suggestions or comments on the draft agenda. My suspicion is that we have enough to talk about without self-describing web
General thought is that it's ok if self describing web is not ready for the F2F