See also: IRC log
<pratul> Here's the new text
<pratul> SML [SML 1.1] defines two reference schemes, the sml:uri scheme and the EPR scheme. The definition of the sml:uri scheme specifies that it is an SML-IF inter-document, but the definition of EPR scheme specifies that it is not an SML-IF inter-document reference. SML also permits new schemes to be created without limit. The definition of each new scheme MUST be explicit about whether the scheme is an SML-IF inter-document reference.
<Marv> 5121: Remove 3.4.3 from SML-IF spec and move bullet point 3 to the SML spec ,
<Marv> The SML spec will then specify that new scheme authors must indicate whether or not the new scheme is an SML-IF inter doc ref.
<Marv> 5171
<Marv> Are multiple xml:base s needed?
<Marv> All to consider xml:base and 5171 overnight.
<Marv> How much latitude do we want to allow in interchange documents?
<Marv> generate minutes
<scribe> scribe: Valentina
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5171
John: producer may not understand
all relative URI's
... if the consumer has these schema available he may be able
to understand them
<johnarwe> if the producer is serializing content, some GEDs may be matching wildcards. if an element matches a wildcard to the producer, it cannot know if relative URIs are contained within the wildcard-matching elements.
Pratul: SMLIF is just a package and the spec should only talk about the content; everything else is out of scope ( such as how a consumer should process some information )
<johnarwe> the consumer on the other hand may have schemas available that allow it to recognize the elements (that the producer sees as wildcard matches)
<johnarwe> therefore the consumer would find an unmodified relative URI and it would not be correctly interpreted
Ginny: how does the producer know what needs to fix in the IF document ; (question relative to the anyURI contained by the IF document) ?
Pratul: do we have agreement on bug 5171 or we should move to thenext bug on the list ?
Sandy: as long as you take a set
of documents and package them in the IF document, their base
uri is lost
... how the consumer know how to unpack the documents ?
Kumar: in SQL implementations,
data is not stored as file system
... so the unpacking of the documents is not an issue here
Pratul: discusses an IF sample
Kumar: there are 4 places from
where you can get the document base URI
... the producer should make sure the document content is right
so that the consumer can understand it
Sandy: there is some information
available on base URI that is not in the IF ( for example on
the file system if file location ); do you suggest to add this
to the IF document ?
... but what if I already have an xml:base attribute ?
Pratul: if there is already one don't add another one
Kumar: document aliases in IF does not represent location, is just a way to identify a document
Sandy: a consumer should be able
to consume IF documents produced by any producer
... so a consumer needs to have some information in the IF
describing how to process the relative URI's
Ginny: can the consumer use the base uri defined for every IF document ?
Sandy: yes, but only when this information is available
Pratul: using base uri for every
document is not seen as a requirement; the producer may choose
to use it, if necessary
... if relative uri's are used in documents, the producer may
probably want to use base uri to define the base in IF
Kumar: if the producer doesn't
understand what is producing how can we assume that the
consumer should understand this information?
... can we summarize what we found before we move to the next
topic ?
John: we need first to understand if we have consenus on what we discussed as valid and supported scenarios
Kumar: will try summarize the discussion..
Pratul: one issue was that
fragment only identifiers should not be fixed by applying
absolute URI
... second issue : the value of the uri base in IF should be an
absolute URI and only one base URI should be defined in an IF
document
... how to preserve absolute URI when documents are packaged in
IF , when the producer doesn't understand the URI?
Kumar: summarizes the issues on
the board : 1. relative URI understood by the producer; 2.
relative URI not understood by the producer
... question : should the producer fix relative URI's for the
case the producer understand them ?
Ginny: expectation that producers will produce content they don't understand
Kumar: question : should the
producer understand all the information in the IF document
?
... notes that implicit notion of structure in relative uri is
lost when packaged in IF
Ginny: what is the next action ?
<scribe> ACTION: Kumar toreview 5171 with Sandy and come back with a proposal [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-134 - Toreview 5171 with Sandy and come back with a proposal [on Kumar Pandit - due 2007-10-23].
Resolution: editorial
Pratul: already discussed, make it dependent on 5171
Ginny: already depends on 5878, which is already resolved
Sandy: Ithink 5171 should be dependent on this one and not the other way around
Kumar: sure, let's do it as Sandy suggests
Resolution: make 5171 dependent on 5181
Pratul: the proposal is to move from xpointer(), Kumar proposes an alternate solution
MSM: this may contradict with the
way the web architecture works
... understands the need for the proposal though
Pratul: what is the problem with this problem ?
MSM: I think we'll get comments
that we took over the task of defining the fragment identifier
scheme
... suggest taking the task of asking for xpath1() scheme
become a recomendation
... if we don't want to use xpointer() scheme because is not a
rec, it's less work if we try to make this a scheme rather than
try to use something else
Pratul: we can define our own scheme in the context of the SML spec; faster than to wait for somebody else to make something a rec
MSM; polite to communicate with the XPath language group and tell them we need this and ask them if they plan for having this as a rec; if not, we plan to address this within our group
Kumar: wonder why this has not been a rec yet and why we can succeed on this in a faster manner?
MSM: probably nobody needed our
level of standardization
... we should ask other group to ake this a rec; if not we can
mmake it part of our spec but probably part of a different
document so that it can be reused
Pratul: nervous that this means
slipping our own dates
... this is also not part of our charter
MSM: seems that how to deal with fragment identifier is part of our spec though
Kumar: a different document may pose a risk to our current dates, we are close to the LC milestone
John: for the record, Paul Groso is okay with us using xpath1() scheme
Ginny: we can define a scheme for xpointer() in our own spec - one option
John: wonders which of the proposed approaches is more likely to go smoothly
Pratul: as a compromise we can use the xpath1() scheme and then have an action to follow up with the wrc group to test if this may be an issue; if an issue, we can incorporate this in our scheme
<pratul> One correction - we use the registered xpath1() scheme
Kumar: propose to define our own xpath1() scheme, choose a name for it and add it as a part of our spec
Ginny: we should also register this scheme
John: wonders what is the process for registering a scheme
Kumar: asks MSM if he is aware of the FixPointer activity and how this relates to the xpointer() scheme since the FixPointer group were originally part of the xpointer() group
MSM: irreconcilable differences
between people who wanted reach support for references resulted
in this new activity
... FixPointer is not actively proposed by anyone
Pratul: for this bug we have two
options; 1. define our own scheme; 2. use xpath1() scheme
... Kumar is not comfortable with option2; he proposes option
1
John: we need to review the scheme registration process so that we know what can be done in terms of updating existing schemes so that we don't end up with issues
Kumar: agrees to review this process; due diligence on the procces
Resolution: use xpath1() scheme
Pratul: next question is whether
we want to create a profile of the xpath1() scheme and use
Kumar's proposal
... proposes to close 4636 and comment that the decision is to
use xpath1()
Kumar: options 1. use xpath1() as is, 2. profile xpath1() 3. define our own scheme
<pratul> 2 should be "profile xpath2()"
Pratul: to summarize proposed approach: use xpath1() scheme and communicate with the wrc team to see if there are any issues with this approach; if any issues are identified then we go with defining our own scheme
<scribe> ACTION: Kumar to investigate if there any implemetation issues with supporting xpath1() scheme [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action02]
<trackbot-ng> Created ACTION-135 - Investigate if there any implemetation issues with supporting xpath1() scheme [on Kumar Pandit - due 2007-10-23].
Resolution: get back to this defect after Kumar and Pratul/John/MSM investigates issues with the proposed xpath1() scheme usage
Ginny: there is a document posted with the latest proposal
latest proposal http://lists.w3.org/Archives/Public/public-sml/2007Oct/0066.html
<johnarwe> http://lists.w3.org/Archives/Public/public-sml/2007Oct/0066.html
Ginny: the proposal is to specify
that cycles are defined on elements; suggestion is to replace
the existing document cycle as described in the spec
... acyclic can be specified on any complex type
... are annotations inherited ?
MSM: no, they are not
... only attributes and content model are inherited
... a way to make an annotation inherited, is to somehow add it
to an attribute
Ginny: an element can have more
children which are ref; this definition allow to define acyclic
on specific child
... use sml:acyclic ref attribute to describe the elements on
which acyclic should be enforced
Sandy: comments that acyclic can
be inherited by making this a requirement in the SML spec; this
is how we deal now with other SML inherited properties,
sml:key
... the proposal is to make the acyclic properties inherited -
should be applied on that type or inherited types
Jim: can this be implemented using schematron rules ?
MSM: only if you use XPath 2.0 and define a recursive function to keep deref'ing the references
Kumar: what if the acyclic is defined on the child instead of the parent and define cyclic any graph getting back to that element or the parent of that element
Sandy: it may not be necessarily on any ancestor
The discussion is around two options on how to define acyclic ; 1. define it at the ancestor level, which bounds it with a node type 2. define it at the reference level
the current proposal ( posted on the bug ) refers to option 1
sample for option 2:
<CT 'nodeType'>
<seq>
<e n="left" sml:acyclic="./left"/>
<e n="right" sml:acyclic="./right"/>
</ref>
</CT>
sample for option 1:
<CT nodeType>
<annotation>
<sml:acyclic ref="./left"/>
<sml:acyclic ref="./right"/>
</annotation>
<seq>
<e n="value"/>
<e n="left"../>
<e n="right"../>
scribe:
</seq>
s/</ref>/</seq>
s/</ref>/</seq>/G
Pratul: propose to resume the discussion at a later time
Jim: should we try to understand what options, 1 or 2, are considered at this time ?
Sandy: option 2 covers the case where the refs don't share the same parent type
break for lunch
rssagent, generate minutes
Resolution: open action item against Ginny to update the proposal based on today's discussions
<scribe> ACTION: Ginny to update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action03]
<trackbot-ng> Sorry, couldn't find user - Ginny
<scribe> ACTION: Virginia update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action04]
<trackbot-ng> Created ACTION-136 - Update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [on Virginia Smith - due 2007-10-23].
<Jim> rrsagent
Kirk: thinks there are usecases where we want to access xs:key and unique from sml:keyref
Kirk's proposal : http://lists.w3.org/Archives/Public/public-sml/2007Oct/0083.html
Kirk: investigated what needs to be added to the SML spec in order to allow such usecases
Kirk decsribes the proposal
Kirk to describe the proposal using a sample - on the board
Kirk: Kumar raised issues with
overlapping symbol spaces for key and keyrefs between xsd and
SML
... bug 5130 addresses constraint symbol space: 'clarify the
extent of SML constraint symbol space '
<sml:keyref name="CoursesStudent" refer="xxx:StudentIDisKey" scope="tns:students">
<sml:selector xpath="course/student"/>
<sml:field xpath="ID"/>
</sml:keyref>
Kirk: scope="tns:students" is the
element in the current complex type where SML reference to
Students is defined
... name=".." and refer=".." is standard
Pratul: asks for group opinion on this proposal
John: is key and keyref actually used in existing documents ?
MSM: there is a large collection of schemas over the net using key and keyref
Kumar: thisnks that the
underlying need is to refer to existing data; you should not be
required to update that data in order to make this happen
... agree with the motivation but feels that schema already
provides this by using xs key and unique
... I think the initial intent was to have sml:key and
sml:keyref defined as close as possible to the xsd
counterparts; feels that this proposal moves away from the
original intent
MSM: thinks that the arguments in favor is that offers clarity and simplicity; cons: overlapping symbol spaces, SML implementations will require to understand xsd key and keyref
Kirk: with the current spec content, sml keyref cannot use existing keys if defined using xml schema
Sandy: no strong opinion; feels like something nice to have and with no other consequences, simple to define and implement
Resolution: xml schema key and unique should be separated from the SML key; make this more explicit in the SML spec
5130 will be looked at later
Sandy: 4115 http://www.w3.org/Bugs/Public/show_bug.cgi?id=4995 seems related to this and is covered by the current bug discussion
Pratul: let's look at 4995 later
Ginny: the spec defines
schematron query binding attribute to be some value that is not
even defined in the schematron spec
... is it a good reason to restrict this query binding ?
Pratul: proposes to go with the
schematron default query binding which is xslt; this should be
the floor
... this statement should go in SML, not SMLIF
Resolution: consensus to fix it as mentioned above
Kumar: for a given target namespace you can't have two constraints with the same name
MSM: trying to understand what
this means in conflicting schemas scenario
... I can't have these constrainsts with the same name and
result in a valid model
Kumar: but we are going to handle the conflicting case in a separate proposal
Resolution: consensus on proposal, update to editorial
Kirk: requires to talk about this tomorrow as there is an ongoing off line discussion that may clarify this
Ginny: conformance section added
to the IF document; want to have something similar in the SML
spec
... something has been added to the SML spec but there are some
changes reuiqred based on feedback
... the document is still changing; want to wait on this
section until the document content is more stable
Resolution: agreement to wait on this
Kumar: doesn't understand the original comments
MSM: tries to remember what he meant
Sandy: comment 1 says that the quoted text is incorrect
<MSM> Proposal: as suggested by comment #2 on 4643, send communication to XML Schema suggesting that they may wish to impose constraints analogous to those of SML, in the interests of (a) alignment and (b) doing the right thing
<scribe> ACTION: Pratul write a proposal to to XML Schema group to address the issue decsribed in 4643 [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action05]
<trackbot-ng> Created ACTION-137 - Write a proposal to to XML Schema group to address the issue decsribed in 4643 [on Pratul Dublish - due 2007-10-23].
Pratul: resolve this wontfix or works for me
John: suggest to mark it wontfix
Ginny: 4643 blocks 5063
Pratul: mark this as editorial as it's covered by Sandy's reference proposal
Pratul: we had a similar discussion yesterday about what producers and consumers should be required
Ginny: not sure if we agreed on something
Pratul: we agreed that consumers MUST support uri scheme; producers are not required to support it
Ginny: we talked about this
yesterday, related to bug 5121 but I don't think we reached
agreement
... assumed that IF constraints both consumers and producers to
support uri scheme
... would like to see this unchanged
MSM: is the requirement on a producer to support the uri scheme a testable requirement ?
Pratul: thinks it is
... the test would be that a consumer that understand only
sml:uri can take a document and understand it; the doc can go
through a round trip exchange and give the same results
Ginny: a level 1 conformant
producer supports all IF scheme minus sml uri scheme
... level 2 consumers will also support sml uri scheme
Pratul: why do we need these 2 levels ?
Ginny: so that consumers that understand different schemes can claim conformance at some level
MSM: thinks is useful to use terms for documents to define level of conformance
Resolution: both consumers and producers are required to support sml uri scheme; a producer should be able to produce IF using sml uri scheme; define 2 levels of conformance for the IF documents; mark the defect editorial
Pratul: this seems to be done, covered by Sandy's reference proposal
MSM: what is the answer here ? 0 or more ?
Sandy: the answer is 0 or 1
Resolution: mark this editorial, covered by the ref proposal http://lists.w3.org/Archives/Public/public-sml/2007Sep/0268.html
Kirk: why are we talking about DTD's ?
MSM: this is DTD's for documents in the model we may want to inline
Kirk: but there is some statement, could not find now, that states XML Schema is the schema to use
MSM: possibility that somebody
chooses to use entity references for special characters, there
is nothing to prevent you using a DTD defining it and XML
Schema for the language
... another posibility is that some people really want to use
DTD and not XML Schema ( old documents, etc )
... to draft something as a proposal
Ginny: this defect is dependent
on 4978
... propose to mark this dependant to 4978
MSM: remarks that it refers to a section that doesn't exist anymore
Ginny: I think it moved under section 6
Sandy: it is 6.1.4
Pratul: looks like a MUST
Resolution: resolve this to MUST and refer to whether to keep err in 4978; mark edittorial
MSM: this is the one reported by
MSM
... does not recall the details
Sandy: feels that this is redundant
Resolution: completely remove
this section
... remove bullet number 3 only
in addition, a similar section should go under the conformance criteria; on the sentence before the bullet change ref from 3.11.2 to 3.11
Pratul: we agreed to make the change in IF so that a new scheme defines if it is or not an IF scheme
Resolution: remove last sentence
move second sentence of the third paragraph to the addresing scheme definition
reword first sentence to say it is not an IF scheme because of the scheme's definition
<johnarwe> last sentence (of 3.4.2, to be removed) is: SML-IF Consumers MUST NOT interpret wsa:address content as inter-document references.
<johnarwe> sandy: do we need to deal with sml:uri for similar reasons in "SML-IF Consumers MUST interpret xsi:schemaLocation hints and sml:uri content used as SML reference schemes as inter-document references."
<johnarwe> proposal: remove "and sml:uri content used as SML reference schemes "
<johnarwe> resolution: consensus on proposed
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/scheme/schema/ Succeeded: s/question relative to the anyURI contained by the document/(question relative to the anyURI contained by the IF document)/ Succeeded: s/Pratul/Kumar/ Succeeded: s/the producer we may probably/the producer may probably/ Succeeded: s/Kumar/Pratul/ Succeeded: s/nnn/nn/ Succeeded: s/URI reference scheme/fragment identifier scheme/ Succeeded: s/ake/make/ Succeeded: s/1.1/1.0/ Succeeded: s/propose/proposed/ Succeeded: s/XPath 1.0 scheme/xpath1() scheme/G Succeeded: s/XPointer/xpointer()/G Succeeded: s/2. profile xpath2()/2. profile xpath1()/ Succeeded: s/speify/specify/ Succeeded: s/area nnotations/are annotations/ Succeeded: s/to describe the elements on which elements/to describe the elements on which/ Succeeded: s/define recursive function/define a recursive function/ Succeeded: s/acylic any graph/cylic any graph/ Succeeded: s/cylic/cyclic/ Succeeded: s/sample for option 2 below/sample for option 2:/ Succeeded: s/<ref>/<seq>/ WARNING: Bad s/// command: s/</ref>/</seq> WARNING: Bad s/// command: s/</ref>/</seq>/G Succeeded: s/which bounds it with a note type/which bounds it with a node type/ Succeeded: s/addresses the/addresses constraint symbol space:/ Succeeded: s/MSMS/MSM/ Succeeded: s/there are/there is/ Succeeded: s/5130 should be fixed/5130 will be looked at later/ Succeeded: s/constrainst/constrainsts with the same name/ Succeeded: s/to handling/to handle/ Succeeded: s/level 1 conformant producers/level 1 conformant producer/ Succeeded: s/minus smo uri/minus sml uri scheme/ Succeeded: s/defining the definition/defining it/ Succeeded: s/3.2.2 to 3.2/3.11.2 to 3.11/ Succeeded: s/new scheme is or/new scheme defines if it is or/ Found Scribe: Valentina Inferring ScribeNick: Valentina Present: Kumar MSM Sandy Jim Ginny Pratul Valentina John Kirk Marv Zulah Got date from IRC log name: 16 Oct 2007 Guessing minutes URL: http://www.w3.org/2007/10/16-sml-minutes.html People with action items: acyclic ginny kumar pratul proposal update virginia WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]