RSE Wiki Archive

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

Attendees:
  * Adam - n/a
  * Alice - ok
  * Dave - n/a
  * Joe - ok
  * Julian - ok
  * Nevil - ok
  * Paul - ok
  * Robert - ok
  * Ted - ok
  * Tony - ok


Agenda

1. The latest on the v2 and v3 vocabulary drafts

Julian - the spec has the vocabulary description and a few additional sections, one of which is the one about the use of certain unicode characters to enforce certain things like non-breaking space.  Vocabulary wise, almost done, with just a few attributes left to describe.  Will submit something by the Friday submission deadline, though it might not be 100% complete yet.

Tony - will the v2 vocabulary need to change to accommodate things like the DOI?  
(Julian) by definition, v2 cannot change any more, and all changes would be in v3.  

(Paul) - Agree with Julian.  What would the changes have to be?  

(Tony) Field data, external identifier reference to the bibliographic references, in the references section.  

(HF note to self) We need to make sure what we need to do is clear in the DOI draft.  Send the link to "what's required to register DOIs" to rfc-design.   

(Paul) we probably don't have to touch v2 to do anything in particular with the DOI URI, since we already use URLs.

(Robert) the text Tony is pointing to discusses something else, a request that you have arguments to xml2rfc where we use includes now so you can include DOIs there and then xml2rfc will build the reference in the manner we expect.  

(Paul) that's not how I read it, but its fine, and doesn't take a change to the vocabulary.

(Julian) we shouldn't add to the vocabulary extensions that are specific to specific citation libraries, databases, or schema.  If we have something, it should be generic.  DOIs might be interesting for us to have, but don't see us citing a lot of documents with DOI, so don't see why we would special case them.

(Paul) agree with Julian on this one.


V3 and backwards compatibility -- Where do we stand with the backwards compatibility debate?  As with this group, rfc-interest split along a gradient of "breaking backwards compatibility is BAD" and "breaking in the name of making this simpler is GOOD"

(Paul) that's the right gradient.  In the abstract, that is the right split.  When we look at the actual changes in the draft today, there are exactly 3, 2 of which are removals of things we don't need any more, 1 we never even used (spanx).  Changing the way that lists work, which is still an open question.

(Joe) if we're going to break backwards compatibility, we should go ahead and question the use of xml entirely and the associated tools that will in turn break with the changes

(Julian) there was agreement that lists need to be fixed, but no agreement on how to fix it.  

(Paul) that discussion now has a concrete way of looking at backward compatibility.  If we say we only want backward compatibility, then tell them to look at lists and come up with a better suggestion.

(Ted) backwards compatibility means different things to different people.  

(Paul) People seem to be ignoring the converter option.

(Julian) what is hard about lists other than they are different than HTML lists?  The changes Paul proposes doesn't actually make things easier.  

(Ted) there is a whole section in the v3 doc that describes new ways to do lists, and they all make lists easier and more intuitive.  

(Julian) with block quotes, we may be introducing just a new way to abuse an element.

(Paul) sensitive to the fact that we are abusing things in the list, but adding just a block quote then indicates this is a quote, and the vast majority are not quotes.  Maybe some formatting advice is required.  (Tony) is indentation a formatting choice?  It's more structure?  

(Julian) we should look at why people are intending things.  Maybe we need a note, 

(Tony) or an attribute for text. 

(Paul) if what people want is something that has a semantic to it that expresses itself in their heads as indented, let's add the semantic. 

(Paul) I feel I do have an understanding of where the trouble with lists are based on the discussion on rfc-i.  

(Julian) those were just my problems, and other people probably have different problems. 

(Paul) your problems got a few +1s, and resonated with some of Paul's items.

(Alice) based on existing docs: people don't use lists at all and use t tags instead; or they want a bulleted list and they don't know how to get it to use hyphens because they do't understand the processing instruction; or they want a word to appear on one line, then a line break, then the rest to appear on the follow line (which may be addressed by the dictionary suggestion) but they abuse t for that.  As far as block quotes "list style=empty" is what they use now for block quotes, and yes, if we had a block quote element, it would be easier to extract that content to validate.  

(Paul) with the things you are seeing, is this in XML?  Yes, this is all from XML files submitted.  

(Ted) one other points about how lists are used now, the way we do lists number is not compatible with how HTML does automatic list numbering, and so it is difficult to get a broken list to have the numbers line up again.  

(Paul) it is different and its funky.  

(Julian) Please send an example of that to the list.  To Alice's point about choosing the symbol int he list, had looked at what HTML does, and most of that functionality is now in CSS not HTML.  In HTML you starts with the statement that this is an ordered/unordered list, and we almost have the same thing in xml2rfc, then using CSS you can override the numbering or symbol that is used (which we do not have in xml2rfc).  We should mirror what HTML allows by having language feature that provides the same level of detail.  (Paul) which I think I did in the draft from last night.  

(Joe) where we can, why not just copy what HTML does?  

(Paul) if HTML pushes this int to CSS, that's not what people know.  Did not go to "ol, ul, el" because we also have definition lists.  Left it with life-style=.  

(Joe) Leave the old one for backward compatibility and allow the new one.  Use deprecated/legacy as a concept.  We are going to have a mixing of semantic between the two which gets confusing.  If we make it explicit rather implicit, it will be clearer to people what we're trying to do.

(Julian) HTML in itself does not have this functionality, only combined with CSS.  Once we start substituting xml2rfc construct with HTML constructs, we end up with a very weird language.  Very confusing.

(Joe) this is why I suggest we go to HTML in the first place.  One of the things we're learning is that as the semantics from XML drift from HTML, it is a problem.  

(Julian) that's why I'm worry about breaking backwards compatibility away from the direction taken by HTML.  We have two different types of list in xml2rfc - the numbered and simple, and the other where we have text labels.  They are different for very good reasons. 

(Joe) suggest that we end up in HTML having predefined classes associated with them

(Julian) we have people asking for the ability to cross ref list items. In HTML you have little control over who the browser displays the list.  You have control how its formatted, but not what the symbols and numbering schemes are. (??)  In HTML you don't have the lists item number in your content, so if you want to reference something you have to 

(Paul) am happy to make minor and massive changes as long as they are generated by a direction.  We've had three orthogonal directions today: maintain backwards compatibility with v2, looks like HTML, and make it easier in new.  Heather needs to put on her tiara and decide.



2. non-ASCII characters and what that means for the xml vocabulary

(Heather) Paul captured the technical requirements underlying the examples well.  HF is doing a bit of wordsmithing here, and will send out a revised doc shortly.

(Paul) Heather designed a protocol or format without saying what the basic requirements are.  Paul does not actually agree with all those requirements.  Specifically, the second one about people who don't have devices that can read the docs.  Those people/devices exist, but they have other options.
This is about creating a text format that is dumbed down to make that second requirement go away.
We don't know which way things are broken for txt documents.  A person looking at the doc will know that it is broken.  

(Joe) go back to the uglification document?  saying plain text docs will be ascii only.  

(Paul) That will still work in the vast majority of cases we're worried about.

(Heather) I want to get Dave Thaler's comment in this as well.

(Robert) presenting a string in UTF-8 then calling out that string for U+ literals, and making sure they say the same thing.  markup would make it easy to do this.  

(Paul)  if we have to do that in figures and artwork, and that artwork is under c-data, then any marking there goes sideways.  That's where we will have the most interesting and problematic use of non-ascii - in a figure, someone says this "IDN domain name is blah" then the diagram includes that information.  There is no sane way to mark that under c-data


3. SVG profile update (Nevil)
Nevil has a revised draft out. Send him comments.

4. PDF to HTML mapping draft update (Tony)
Tony has not received much input.  Encouraged to take this to rfc-interest.

5. Editor change for HTML draft (Heather/Joe)
Heather is taking the pen on this draft; working with Joe on the logistics of transition during a call tomorrow.  Probably won't have an updated draft in the system before Friday.


6. February 26 call?  Think about it.
RSE Wiki Archive

User Tools

Site Tools

Page Tools
